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Preface 


This manual describes Systems Network Architecture/Distribution Services 
(SNA/DS) at the implementation level. This manual does not describe any spe- 
cific machines or programs that may implement SNA, nor does it describe any 
implementation-specific subsets or deviations from the architectural description 
that may appear within any IBM SNA product. These matters, as well as infor- 
mation on SNA product installation and system definition, are described in the 
appropriate publications for the particular IBM SNA machines or programs to 
be used. 
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Chapter 1. 


Introduction 


Concepts and Facilities 


SNA/Distribution Services (SNA/DS, or simply DS) provides a general-purpose, 
connectionless communications service to applications that use it. A 
connectionless service is one in which communication is performed without the 
establishment of a direct connection between (or among) the communicating 
parties. Such a service is also commonly known as a messaging service. In 
contrast, a connection-oriented service is one that does provide a direct con- 
nection between the communicating parties. DS is connectionless at the trans- 
action services layer of SNA; from the DS perspective, an SNA session (or more 
precisely, an LU 6.2 conversation) between two application programs is an 
example of a direct connection between those programs. 


DS allows application programs to communicate without requiring that the 
origin and destination of the communications both be active simultaneously. 
The architecture allows the nodes at which the origin and destination applica- 
tion programs reside (not those application programs themselves) to communi- 
cate via direct sessions. Alternatively, those nodes may communicate via 
intermediate nodes that provide a store-and-forward function. Traffic is queued, 
if necessary, before being sent from one node to the next. 


The connectionless nature of the service does not necessarily imply long delays 
in completing the processing of requests. It does imply that the communicating 
application programs do not interact and therefore that responsibility for the 
unit of work cannot be shared but must be shifted. The originating application 
program transfers responsibility for a request to the distribution service, which 
subsequently transfers the request to the destination application program. 

Once the distribution service has accepted the request, it is independently 
responsible for carrying it out, perhaps within milliseconds, perhaps not for 
hours. 


The distribution service (Figure 1 on page 2) consists of a network of nodes 
known as distribution service units (DSUs). This network may be thought of ini- 
tially as occupying a geographic area of no particular shape. The entities that 
use the distribution service are outside the boundary of that area. The service 
accepts requests from, and makes deliveries to, those entities across that 
boundary. 


The unit of work performed by the service is termed a distribution. A distrib- 
ution begins at one DSU and may spread out to many. The work performed on 
a distribution includes the acceptance of the request at the origin, the gener- 
ation and movement of copies of the distributed material across the network, 
and the delivery of those copies to the specified destinations. Various levels of 
service may be requested for distributions: for example, higher or lower priori- 
ties. 
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SNA/DS utilizes and complements the services provided by the lower layers of 
SNA. Distribution service units communicate with one another via LU 6.2 basic 
conversations. Users of DS perceive the distribution service as just part of the 


overall SNA services. 
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Figure 1. SNA/Distribution Services Network 


The Interface to the Distribution Service 


Agents 


Agent Requests 


DS performs services in response to requests issued by application transaction 
programs. These application transaction programs are known as agents. 
Agents exist outside the boundary of the DS network (Figure 2 on page 4), and 
provide users and/or service functions with access to DS services. Agents may 
send distributions, receive distributions, or issue operations commands on 
behalf of their users. There is a many-to-many relationship between users and 
agents; that is, an agent is typically capable of acting on behalf of a variety of 
users, and users typically make use of a variety of agents. 


The originating agent requests that DS perform a distribution. The request 
specifies the data object (or objects) that is to be distributed, and specifies the 
name of the agent that is to be invoked at the destination(s) to process the dis- 
tribution. 


The request also specifies one or more destinations, which may be either users 
or DSUs or a mixture of both. (Similarly, a user (or a DSU) could receive dis- 
tributions originated on behalf of other users or on behalf of DSUs.) An origi- 
nator would specify a user as a destination to send information to that 
particular user. The originator need not know the locations of users; DS deter- 
mines the location of each destination user specified. The originator would 
specify a DSU as a destination in order to send information to a particular 
location in the network, perhaps to a service function (not a user) at that 
location. | 
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If the originator supplies a user name as a destination, the destination is 
referred to as a user destination. lf the originator supplies a DSU name as a 
destination, the destination is referred to as a node destination. 


Small objects to be distributed may be imbedded directly in the originator’s 
request. Larger objects are typically not passed directly to DS by the agent, but 
are referred to by name or location so that DS can access them when needed. 


Several other parameters are included in the request, some required, some 
optional. This chapter introduces certain key parameters. For a complete 
description, refer to Appendix F. 


The Agent Protocol Boundary 


Agent Names 


The interfaces across which DS interacts with non-DS entities are called pro- 
tocol boundaries (PBs). The particular interface across which DS§ interacts with 
agents and operators is called the agent protoco!l boundary. Other protocol 
boundaries defined by DS are the server protocol boundary and the queue pro- 
tocol boundary. I|In addition, DS communicates with LU 6.2 via the LU 6.2 basic 
conversation protocol boundary. 


A protocol boundary defines the functions provided by and expected by the 
components on either side of that boundary. It does not necessarily define the 
precise syntax of requests issued across it. For more information on the pro- 
tocol boundaries defined by DS, see Appendix F. For more information on the 
LU 6.2 basic conversation protocol boundary, see the Transaction Programmer's 
Reference Manual for LU Type 6.2. 


The information contained in requests made by agents across the agent pro- 
tocol boundary is formally defined in DS by several protocol boundary verbs. 
The two basic verbs are: 


1. Send_Distribution. This verb is issued by an agent to request that a distrib- 
ution be performed. Its parameters include the destination users or DSUs 
and the name of the agent to be invoked at the destination to receive the 
distribution. 


2. Receive Distribution. This verb is issued by an agent that is activated at 
the destination to accept delivery of a distribution. 


In addition, several other verbs provide variations of the basic sending and 
receiving capabilities. Refer to “Agent Protocol Boundary Verbs” on page 55 
and to Appendix F for further information about agent protocol boundary verbs. 


Agents have names. At any given location in the network, an agent name 
uniquely identifies a specific application program. (There may, however, be 
multiple instances of a particular agent at a particular location.) Typically, a 
given agent name is known at multiple locations, and there are many instances 
of that particular agent throughout the network. Agents may be either user- 
written or architecturally defined. 


A requesting agent must specify the name of the destination agent that will be 
activated to receive the distribution on behalf of the destination users or DSUs. 
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The Transfer of Re 


There is only one destination agent per request, no matter how many destina- 
tions are specified. 


sponsibility 


When the originating agent requests that DS perform a distribution, the agent 
transfers responsibility for the distribution to DS. Once the distribution service 
has accepted responsibility for a request, it performs the distribution independ- 
ently; the originating agent is no longer involved. 


While DS has responsibility for the distribution, exceptions may occur. If the 
originating agent has so specified, exception reports will be generated and sent 
to a specified user or DSU. When the report arrives, an agent will be invoked 
to handle it; this agent may be a different instance of the originating agent or a 
completely different agent. Reporting is thus performed asynchronously. This 
contrasts with synchronous exchanges that occur between transaction pro- 
grams that communicate entirely within one conversation. 
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Figure 2. A DS Network Showing Agents 


Distribution Service Users 


Users of DS are defined as addressable entities on whose behalf agents can 
originate or accept delivery of distributions. Users may include individuals, 
departments, application programs, and data bases. Users of DS may include 
individuals or application programs with responsibilities for system and network 
operations or for installation and maintenance of network definition information. 
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User Roles 


User Names 


Users are referred to as originating users or originators when they request (via 
their agents) that a distribution be performed, and as destination users when 
distributions are delivered to them. Most users are capable of either role; 
however, it is possible for a user such as a data base to serve only as a desti- 
nation. 


DS users have names that are unique within the DS network. A user name 
consists of two parts, each of which can be up to eight bytes long. The two 
parts are known as the distribution_group_name (DGN) and the 
distribution_element_name (DEN). Each element name is unique within its 
group, and each group name is unique within the network. 


Users, or their agents, must know the names of all the other distribution service 
users to whom they wish to send distributions. To facilitate this, user names 
could be publicized throughout an organization, exchanged over the phone, and 
included on letterheads. 


An organization assigns group names based on whatever structure is most 
natural for it. Divisions or departments might be convenient group names; last 
names might be convenient element names. For example, Harry Chase in the 
Operations department could be OPs.cHASE, and Ellen Piaf in the Marketing 
department could be MKT.PIAF. 


Users, however, are not necessarily people. For example, there might be a sta- 
tistics data base in manufacturing to which various plants routinely ship data. It 
could have MFG.DBASE as its user name. Other user names might identify 
departments (BIGBANK.LOANS), applications (ACCTG.PAYROLL), or titles of positions 
(DEPTX.MGR). 


Users in the same group (i.e., with the same DGN) need not be located near 
one another in the network. Furthermore, members of several groups might 
reside at the same location in the network. For example, at Paris, there might 
be users in the loans (LOANS.PIERRE), payroll (PAYROLL.PORTER), and personnel 
(PER.PEDRO) departments. Other users in these same departments could be 
located throughout the network; for example, PAYROLL.CHARLES might be located 
in Chicago, and PAYROLL.NORTON might be located in New York. 


DS user names are location-independent. When installations select user names 
with no suggestion of location, users can be moved from one computer system 
to another without needing to change their names. Since DS does not tie user 
names to particular locations, users with location-oriented names could also be 
moved without changing their names, but it would be confusing to continue to 
refer to someone as CHICAGO.SMITH after he had moved to Atlanta. 
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User’s View of the Distribution Service 
The user’s view of the distribution service is shown in Figure 3. The user 
names are all unique, and are scattered around the periphery of the network 
with no regard to location. The agent names are not unique; numerous agent 
instances exist for each agent name. 


When users request distributions with no server. objects (a concept discussed 
later), user names and agent names are the only names of which users need 
be aware. When server objects are involved, the users (or their agents) must 


be aware of certain other additional names. These are discussed in “Servers 
and Objects” on page 40. 
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Figure 3. User’s View of the Distribution Service 


Distributions | | 
A distribution is the unit of work performed by DS. The distribution starts as a 
request made by the originating agent, and continues through when the distrib- 
uted material is delivered. If the agent requests notification on the status of the 
distribution, DS generates distribution reports to provide such notification. Dis- 
tribution reports are considered part of the same unit of work (i.e., the distrib- 
ution) as the agent’s request. 


Agents may make distribution requests on behalf of either users or the DSUs at 
which the agents reside, and may specify destinations that are either users or 
DSUs. When multiple destinations are specified, DS provides, or arranges 
access to, a copy of the distributed material in a machine-readable form (on 
disk storage, for example) for each of the named destinations. 
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Distribution Copies 
From the perspective of the originator, a distribution includes the delivery of a 
copy to every destination on the destination list. From the perspective of a par- 
ticular destination, the distribution consists of one delivery. Different points in 
the DS network may deal with different subsets of the original list of destina- 
tions. In summary, therefore, a distribution refers to work being done upon 
one, some, or all of its copies, depending on the perspective. 


Types of Information in a Distribution 
A distribution contains essentially two types of information: the “application” 
information that the agent has submitted to DS for distribution, and the DS 
control information that flows along with and encloses the application informa- 
tion. The distinction between these two is analogous to the distinction between 
the pages of a letter and the envelope that encloses them. The DS control 
information is analogous to the name, address, and handling instructions 
written on the envelope. When the distribution flows across the network, the 
application information is clearly separated from the control information; that is, 
it is contained inside the “envelope.” 


Distribution Transport Message Units 
DS uses Distribution Transport Message Units (DTMUs) to transport the origina- 
tor’s information to the destinations named in the distribution request. Whereas 
a distribution is thought of as flowing through a network, possibly through 
several DSUs, a DTMU is thought of as existing only between adjacent DSUs. 
That is, the DTMU is “born” when it is encoded at a particular DSU; it is then 
transmitted to an adjacent DSU, and “dies” when it is decoded by that DSU and 
converted to an internal format (such as a data structure). 


The structure of a DTMU is shown in Figure 4 0n page 8. The DTMU is intro- 
duced by a prefix and concluded by a suffix. The DS control information for the 
distribution is contained in the command; the names of the users or DSUs for 
which this particular copy of the distribution is destined are encoded in the des- 
tination list. 


The information submitted for distribution by the originator is contained in the 
agent and/or server objects. The agent object is intended for small amounts of 
data that can be stored by DS and passed directly to the destination agent. 
Larger amounts of data, or data that requires a particular kind of handling 
(encryption, for example, or specialized parsing) usually flow in the server 
object. Agent and server objects will be discussed further under the section 
“Servers and Objects” on page 40. 


A detailed description of the encoding for DS message units is given in 
Appendix G. | 


The layers of SNA below DS may divide DS message units (MUs) into smaller 
pieces or assemble several small DS MUs into a single large piece, but DS is 
unaware of such manipulations. No direct relationship exists between seg- 
menting performed by DS and the techniques used by lower layers of SNA. 
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Figure 4. Structure of the Distribution Transport Message Unit 


Distribution Report Message Units 
As part of the distribution request, the originator may ask that DS provide feed- 
back on the status of the distribution. For example, the originator might wish to 
be informed if DS is unable to deliver the distribution. DS sends such feedback 
information in distribution reports, which flow through the network in Distrib- 
ution Report Message Units (DRMUs). The structure of DRMUs differs from that 
of DTMUs. DS reporting and DRMUs are discussed in the section “Distribution 
Reporting” on page 66. 


The term distribution message unit (DMU) is sometimes used to refer to either a 
DTMU or a DRMU. 


The Distribution Identification 
Each distribution in the DS network is uniquely identified by a combination of 
fields carried in the DTMU. These fields are known collectively as the distrib- 
ution identification (dist_ID). The dist_ID is composed of the name of the origi- 
nating agent, the name of the DSU at which the distribution was originated, the 
name of the user, if any, on whose behalf the distribution request was made, 
the date of the distribution, and a sequence number. 


Sequence number counters are maintained for each user-agent combination; 
that is, a different sequence number counter is kept for each combination of 
local user and local agent name. An additional counter is kept for each local 
agent that may originate distributions on behalf of the DSU itself (with no origin 
user involved). 


DS Format Sets 
Previous implementations of DS have used a different set of encoding rules for 
distribution message units. The earlier encoding for DMUs is referred to as DS 
Format Set 1; the current set of encodings is referred to as DS Format Set 2. 
Both sets of encodings are documented in Appendix G. The rules that allow 
these two format sets to coexist are documented in Appendix D. 


Distribution Service Unit (DSU) 
A distribution service unit (DSU) is the collection of transaction programs and 
data structures that provide the distribution service at any given location in a 
DS network. These transaction programs are distinct from application trans- 
action programs such as those that issue requests to DS. The DS transaction 
programs are examples of SNA service transaction programs. 
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DSU Roles 


DSU Names 


DSUs have roles that vary with each distribution they service. The DSU at 
which a distribution request originates is the origin DSU for that distribution. 
The same DSU would have the role of destination DSU for a distribution sent to 
users located at that DSU. Alternatively, the DSU may perform a purely inter- 
mediate role. In this case, distributions are received and stored at the interme- 
diate DSU, then forwarded to other DSUs. 


A DSU may perform multiple roles for a distribution. For example, a user at a 
DSU might send a distribution to another user at the same DSU. The DSU, in 
that case, would be both the origin and the destination of that distribution. 


DSU names consist of two parts, each of which can be up to eight bytes long. 
The two parts are known as the routing group name (RGN) and the routing 
element name (REN). Each element name is unique within its group, and each 
group name is unique within the DS network. Typically, the names will be 
assigned to be meaningful to systems programmers and operations people, not 
to the user population. A DSU includes its unique DSU name in all distributions 
it originates. 


The DSU/User Relationship 


Every DS user attaches to the DS network at a DSU. Typically, a DSU has 
several users, although it is possible for DSUs to have no users. 


The DSU is not aware of anything above the protocol boundary it has with appli- 
cation transaction programs other than the names of its users, agents, and 
certain control information used to deliver distributions to them. The users 
themselves may be physically remote from the processor containing their DSU, 
but as far as DS is concerned they are located at that DSU. 


Environment of the DSU 


Figure 5 on page 10 illustrates the various entities with which a DSU interacts. 
Pictured above the DSU are those entities that issue commands to it. The 
agent is an application program that requests DS services. The operator issues 
commands to perform system or network maintenance functions. 


DS interacts with servers in order to access large data objects for distribution. 
The server provides storage of objects that the DSU receives in distributions; it 
retrieves objects to be sent in outbound distributions. 


DSUs communicate with one another via LU 6.2 basic conversations; they rely 
on the local operating system for facilities such as queue handling. 


Subsequent sections of this chapter will explore the DSU’s relationship to each 
of these components. A detailed description of the various protocol boundaries 
is given in Appendix F. DS’s usage of LU 6.2 basic conversation verbs is docu- 
mented in Chapter 2. 
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Figure 5. Environment of the DSU 


DSU Directories and Routing Tables 


A DSU’s Directory 


The DSU directory includes certain information for each DS user. (Directories 
shared with other functions might contain other information of which DS would 
be unaware). The directory entries for local users contain information used for 
DS delivery to those users (for example, a local queue name). Entries for users 
at other DSUs usually contain the name of the DSU at which they are located. 
Exceptions to this are discussed in “Redirection” on page 35. 


The number of users in the network can be much larger than can be conven- 
iently contained in the directory of a particular DSU. See “Default Directing” on 
page 36 to learn how distributions can be directed in cases where the origin 
DSU’s directory does not contain entries for the destination users. 


Users need not be aware of the names of DSUs at which other users reside. 
Users specify only the user names to which a particular distribution is to be 
sent; DS uses the directory to map those user names to DSU names. 


When organizations set up their user names appropriately (that is, with no | 
location or DSU implications), users can be moved from one DSU to another 
without having to change their names. For example, in large networks, groups 
of users are often shifted from one computer system to another because of 
office space rearrangements, or in order to balance loads on computing equip- 


10 SNA/Distribution Services Reference 


ment. The impact of such changes is confined to the directories. The DSU 
name for each affected user is changed, but the user name itself is not 
changed. This means that user names can be completely insulated from the 
DSU name change and can be published or otherwise disseminated throughout 
an organization without concern for obsolescence due to system changes. 


User names themselves may change from time to time. However, if they are 
appropriately assigned, those changes would be the ones of which other users 
should normally be aware. For example, if a user’s department were part of a 
user name and the user changed departments, then the user’s name would 
have to be changed. Users throughout the network would have to be notified, 
but it is likely that those users would need to know about the job change 
anyway (and change their distribution requests accordingly). 


Implementations may allow directory entries to be subdivided by agent name. 
That is, instead of one entry per user, the directory might have several entries 
per user, each of which identifies a different combination of user name and 
agent name. At a destination DSU, such entries might allow distributions for a 
particular user to be delivered to different local delivery queues, based on the 
destination agent name. 


In addition to the entries for users, directories may contain an entry for the 
omitted user name. During the directing process, any destination for which no 
user name is specified (i.e., a node destination) would match such an entry. 
Like user name entries, an entry for the omitted user name may be subdivided 
by agent name. 


User Aliases: To DS, user names represent only entries in the directory. 
Installations can assign user names to entities in any manner they wish. Ali- 
asing is an interesting illustration of how such assignments could be made. 


An individual can be given more than one user name. DS cannot tell when this 
has been done. It “sees” different users because each name has its own inde- 
pendent entry in the directory. When the two entries have the same local 
delivery information, distributions for either name are delivered to the same 
individual. For example, DEPT72.MGR and EMPNO.X12345 could both be defined in 
the directories so that local delivery was made to Harry Jones. Other users 
interested in the work of department 72 would probably use DEPT72.mMGrR. Users 
in Personnel or Payroll would probably use EMPNO.X12345. 


If Harry Jones were to be transferred to another job at another location, the 
EMPNO.X12345 directory entries would be updated with his new DSU name. The 
DEPT72.MGR name, on the other hand, would probably be reassigned to the 
person who replaced him. 


User Names vs. Nicknames: DS user names are not to be confused with nick- 
names. For reasons of convenience, or perhaps some system limitation, it is 
often desirable to refer to users by other, usually shorter, names. For example, 
an originating user might not wish, or might not be able, to logon to his system 
with a 16-byte name. Also, he might not wish to enter 16-byte names for the 
destination users, particularly those to whom he sends things frequently. In 
such cases, nickname files can be used. Such files are not part of DS. The 
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nicknames would not flow in DS MUs, except perhaps as part of the user’s data. 
The nicknames would be unique only within a DSU or perhaps only for one 
user. 


Nickname files are not defined by the DS architecture, but they would need to 
contain the full network-unique DS user name for each nickname. The origin 
agent might access the nickname file to obtain the DS user name that would be 
included in the distribution request. DS, however, would be unaware that such 
files existed. The complete DS user name flows over the network and is used 
in exception reporting. The users are aware, not only of local nicknames, but 
also of complete user names, both their own and those of others to whom they 
wish to send distributions. 


The overall responsibility for the creation and maintenance of the directories 
would usually be the system administrator’s. In a large organization, this could 
be a major task. The two-part user name and default directing (see “Default 
Directing” on page 36) can be used to allocate this responsibility by group 
name. For example, if the DGNs were departments, each department could be 
made responsible for its own set of DENs. 


A DSU’s Routing Table 
In the simplest case, the routing table consists of one entry for each destination 
DSU. Each entry identifies the connection to be used to send distributions to 
that particular destination. The routing table and the directory serve distinctly 
different purposes. The directory indicates where a user is located; the routing 
table indicates how to get there--that is, which direction to go. 


Refer to “Distribution Service Parameters” on page 23 and “Default Routing” 
on page 38 for a more complete description of the routing table entries. 


The creation and maintenance of routing tables is the responsibility of the 
system administrator. Like directory maintenance, this is a significant task. 
Although a typical network could have 10 to 100 times more users than DSUs, 
the number of routing tables in which each DSU name appeared would be 

much greater than the number of directories in which the typical user name 
appeared. Default routing allows the number of entries in the routing tables to 
be considerably reduced. With default routing, a distribution may be routed to a 
larger DSU which would have a more complete routing table. The use of 
default routing is described in “Default Routing” on page 38. 


Simple Networks 


A DS network is a collection of two or more DSUs and the connections between 
them. ADS connection is the set of actual or potential LU 6.2 conversations, 
using a particular LU 6.2 mode name, between two DSUs. DS connections 
share the underlying path control network with sessions belonging to other 
applications. A DS connection may consist of one or more than one LU 6.2 con- 
versation. 
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Fully-Connected DS Networks 
A fully-connected DS network is one in which every DSU has a connection to 
every other DSU. Networks can be set up this way if the underlying layers of 
the SNA network provide total interconnectability. We will use a very simple 
fully-connected network (Sample Network #1, Figure 6) to illustrate the con- 
cepts of simple directing and routing. 


There are four users in sample network #1, located in three cities. Their names 
are listed by department under their cities. The boundary of the DS network is 
shown intersecting three boxes, one in each city. The boxes represent 
processors; the portion of each processor that is inside the DS boundary 
includes a DSU. Each DSU is labeled with its DSU name. 


The small boxes inside each DSU represent a user directory and a routing 
table. The portion of the DS boundary that intersects each processor is the 
agent protocol boundary in that processor. The lines connecting the DSUs are 
DS connections, and are identified in Figure 6 by the pair of names of the two 
DSUs they connect. 
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Figure 6. Sample Network #1 


Simple Directing in Fully-Connected Networks 
The directing function is the process of associating a destination location name 
with a destination user name. In the mail analogy, it would be the process of 
adding the address to the addressee’s name on the envelope. In DS, it is the 
process of associating either a DSU name or local delivery information with 
every user name in the distribution. 
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The simplest kind of directing occurs when every DSU has a complete directory 
of all users. The following discussion presumes that. In practice, such a 
simple situation would probably never occur. The more sophisticated kinds of 
directing are described in “Redirection” on page 35 and “Default Directing” on 
page 36. 


At the origin, the directory is used to obtain the corresponding destination DSU 
name for each destination user name in the distribution. Both the user names 
and the corresponding DSU names are then included in the control information 
that flows in the distribution. Directing is bypassed at the origin for node desti- 
nations. 


At the destination, the directory is used to obtain the information needed to 
deliver the distribution. This information is used locally only; therefore, it is not 
defined by the DS architecture. Typically, it would consist of a queue identifier; 
different queues would be used to deliver distributions to different users. 
Directing is performed at the eran ison DSU for both user and node destina- 
tions. 


Figure 7 on page 15 illustrates the directories and routing tables for sample 
network #1. Recall that directories may contain an entry for the omitted user 
name; note the entry at Us.Nycsys1 for “omitted.” The significance of this entry | 
is that a distribution with an entry in the destination list specifying US.NYCSYs1 
(no destination user name), when received at New York, would be delivered to 
the local queue sysqi. 


Simple Routing in Fully-Connected DS Networks 
Routing is the determination of the next route segment on which a distribution 
is to be sent, and the scheduling of or enqueuing for the sending activity. 


The simplest kind of routing occurs when every DSU’s routing table contains 
entries for all other DSUs. The following discussion presumes that to be the 
case. More sophisticated routing is described in “Default Routing” on page 38. 


Each entry in the routing table identifies the DS connection over which distrib- 
utions are to be sent in order to reach a particular destination DSU. In this 
illustration (Figure 7), with only one type of DS traffic, the connections can be 
uniquely identified by the pair of names of the DSUs they connect; however, in 
the routing table of one DSU only the name of the other DSU is required. This 
is contained in the column labeled “Next DSU.” There is no particular DS defi- 
nition of connection identifiers, so implementations may use different identifiers. 
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Figure 7. Directories and Routing Tables for Sample Network #1 


MU Flows for Typical Distributions 


A Single-Destination (Non-Local) Distribution: In Paris, Piaf in Marketing wishes 
to send a message to Chase in Operations. Her agent requests a distribution, 
identifying the originating user as MKT.PIAF, the destination user as OPS.CHASE, 
and the destination agent as agent X. The DSU at Paris consults its directory 
and determines that OPS.CHASE is at US.CHISYS2. The destination US.CHISYS2 is 
then used to determine from the routing table the connection for which the dis- 
tribution should be enqueued. In Figure 8 on page 16, the box labeled DTMU-A 
represents the DTMU that flows. Only the control information pertinent to this 
discussion is depicted in DTMU-A. 
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Figure 8. Single-Destination Distribution 


A Multi-Destination Distribution Fanned Out at the Origin: In Paris, Piaf 
requests that a message be sent to Chase in operations and Neff in Marketing. 
As in the single-destination example, the DSU at Paris determines the destina- 
tion DSU names and uses them to determine the routing. In this case, 
however, there are two destination DSUs. The DSU at Paris therefore sends 
two copies of the distribution as shown in Figure 9 on page 17. Notice that the 
control information in the DTMUs depends on the destination. The process of 
creating additional copies of a distribution is known as “fan-out.” 
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Figure 9. Multiple-Destination Distribution with Origin Fan-out 


A Distribution Fanned Out at the Destination: In Paris, Piaf requests that a 
message be sent to the DSU at New York, with copies to Child in manufacturing 
and Chase in operations. The Paris DSU consults the directory for the two user 
destinations (MFG.CHILD, OPS.CHASE) and discovers that MFG.CHILD is at the same 
DSU as OPS.CHASE. It therefore sends only one DTMU to US.CHISYS2 and includes 
both user names in it. Refer to Figure 10 on page 18 and notice the contents of 
DTMU-A. 


No directing is performed at the origin for node destinations, since the origi- 
nator has already supplied the DSU name. Thus for the destination US.NYcSsyYs1, 
no directing is necessary. The routing table is consulted to determine the con- 
nection to use for US.NYCSYS1. 


Since Child and Chase each have their own queues, the Chicago DSU creates 
an extra copy of the distribution. It places one copy in queue USERQ1 and the 
other in queue USERQ2. In some systems, users might be able to share the 
same copy of the distribution and there would be no need for the copying step. 
If Child and Chase happened to share the same queue, DS would make a single 
delivery containing both user names. 


At New York, the distribution copy destined for Us.Nycsys1 is received. Directing 
is invoked; since there is no user name for this destination, the entry for 
“omitted” is matched. The distribution is placed in queue sysqi, the destination 
agent x is started, and the distribution is passed to it. 
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Figure 10. Multiple-Destination Distribution with Destination Fan-out 


DS Networks with Intermediate DSUs 
| This type of DS network differs from the simple type discussed above in that the 
DSUs are not fully connected. In order for distributions to travel between 
certain DSUs, other DSUs must perform an intermediate role. The use of inter- 
mediate DSUs to forward distributions provides functional and performance 
advantages. 


The sessions used by DS connections sometimes span multiple path control 
(PC) intermediate routing nodes (IRNs). In these cases, the PCIRNs are often 
geographically close to a node containing a DSU. For example, consider 
sample network #1 in Figure 6 on page 13. The processor in New York that 
contains the DSU is a System/370. Directly attached to that processor is a com- 
munication controller, through which the sessions used by the 
(EUR.PARSYS1-US.CHISYS2) connection pass. This is illustrated in Figure 11 on 
page 19. The components of the path control network are depicted by dotted 
lines. The presence of the PCIRNs is transparent to DS; the DSU sees only the 
direct session to its partner DSU. 
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Figure 11. Sample Network #1 Showing Underlying Path Control Network 


In the case of the distribution from Piaf at Paris to Neff at New York and Chase 
at Chicago, two copies of the one distribution travel across the same 
transatlantic link (the dotted connection between the PCIRNs in Figure 11). For 
large distributions, such duplication is rather wasteful. 


To avoid this inefficiency, large distributions destined for US.CHiSYs2 are sent 
first to US.NYCSYS1, where they are received completely and then forwarded. 
The direct DS connection between EUR.PARSYS1 and US.CHISYS2 in sample 
network #1 is broken into two shorter ones. The two-connection version of the 
network is shown as sample network #2 in Figure 13 on page 21. 


Simple Directing in Networks with Intermediate DSUs 
Directing in this type of network at the origin and destination DSUs is the same 
as in fully-connected networks. In the simple case, directing is not invoked at 
intermediate DSUs. The routing function is all that is involved at a DSU per- 
forming a purely intermediate role. An exception to this is described in 
“Redirection” on page 35. 
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Simple Routing in Networks with Intermediate DSUs 


In this type of DS network, the structure of the routing tables is the same as in 
a fully-connected one. That is, each entry identifies the connection over which 
distributions are to be sent in order to reach a particular destination DSU. The 
difference is that, for a route involving intermediate nodes, the connection iden- 
tified in the entry does not connect the origin and destination DSUs. For 
example, refer to Figure 12. In Chicago, the entry for EUR.PARSYS1 identifies a 
connection with Us.Nycsys1; in Paris, the entry for US.CHISYS2 identifies a con- 
nection with US.Nycsys1. The New York routing table remains the same as in 


sample network #1. 
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USER DIRECTORY 
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ROUTING TABLE 


Destination| Connection 
(Next DSU) 


US.CHISYS2 | US.NYCSYS1 
US.NYCSYS1 |US.NYCSYS1 


EUR. PARSYS1 


Figure 12. Directories and Routing Tables for Sample Network #2 


This slight difference in content reflects a significant difference in concept. In 
DS, a route is defined as the sequence of DSUs through which a distribution 
has traveled when it arrives at its destination DSU. The routing function is per- 
formed independently at each DSU. At any particular DSU, the routing function 
does not select a route in its entirety (except where there happens to be a 
direct connection). The routing function actually selects a route segment. The 
notion of route segment differs from the notion of connection in that segments 
of more than one route may use the same connection. In sample network #2, 
the connection EUR.PARSYS1-US.NYCSYS1 is used by segments of two routes, one 
from EUR.PARSYS1 to US.NYCSYS1 and the other from EUR.PARSYS1 to US.CHISYS2. 


Because, in some implementations, operators could change routing tables as 
distributions move through the network, the route for any particular distribution 
cannot be reliably predicted at its origin DSU. Each distribution finds its own 
way across the network, one route segment after another. Two distributions 
from the same origin might find different routes to the same destination. 
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MU Flows for Typical Distributions 
Single Destination Through an Intermediate DSU: Figure 13 shows the two- 
connection network (sample network #2) with a single-destination distribution 
flowing from Paris to Chicago. The DSU at Paris determines that distributions 
for Chicago should be sent on the connection to New York. When the DSU at 
New York receives the distribution, it examines the destination list and dis- 
covers that there is no local destination. It then uses its routing table to 
forward the distribution on the connection to Chicago. 


NEW YORK 


CHICAGO Agent PB 
Rtg Table 
US .NYCSYS1 


EUR.PARSYS1} . 


DTMU-A 
.-from MKT.PIAF at EUR.PARSYS1...to 
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US. CHISYS2 


DTMU-B 
«. from MKT.PIAF at EUR. PARSYS1..to 
OPS.CHASE at US.CHISYS2...Dest Agent=X 


Sample Network #2 


Figure 13. Single-Destination Distribution Through an Intermediate DSU 


Distribution Fanned Out at an Intermediate DSU: In the two-connection network 
(sample network #2), the distribution from Piaf in Paris to the DSU in New York 
and Chase and Child in Chicago is not fanned out by the Paris DSU. When the 
DSU determines that distributions for US.CHISYys2 should be sent to US.NYcsyYs1, it 
sends only one copy over the transatlantic link (see Figure 14 on page 22). In 
New York, the DSU delivers one copy of the message (for the node destination 
US.NYCSYS1) to the destination agent x, and forwards another copy to US.CHISYS2. 


Notice how the control information in DTMU-B differs from that in DTMU-A. The 


US.NYCSYS1 destination information is stripped out when the distribution goes 
through the intermediate DSU. 
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Figure 14. Multiple-Destination Distribution with Intermediate Fan-out 


Advantages of Using Intermediate DSUs 
Reduced Connectivity Costs: The number of possible direct connections in a 
network is (n(n-7))/2, where n ts the number of DSUs. If it is desired that direct 
sessions be used for all DS communication, this is the number of connections 
required. 


DS networks could contain thousands of DSUs. If full interconnection is desired, 
millions of sessions would be required. Each DSU would need to have thou- 
sands of sessions. Only a small fraction would be active at any given time, but, 
nonetheless, the resources required would be unreasonably large. 


Intermediate DSUs can be used to reduce this cost. If, instead of a fully inter- 
connected network, all DSUs are connected to just one intermediate DSU, the 
total number of connections is n-7. When n is large, the savings in connection 
resources are dramatic. With 1000 DSUs the number of sessions needed is 
reduced from 499,500 to 999, a factor of 500 (i.e., n/2). In practice, rather than 
one intermediate DSU, a backbone network of 10 or 20 intermediate DSUs 
would be used and more sessions, perhaps another 200, would be needed. 
Even so, the resource savings are dramatic. 


Improved Link Utilization: It is expected that some types of DS traffic will travel 
on sessions having lower transmission priority than the sessions that handle 
interactive traffic. Interactive loads fluctuate; the low-priority sessions serving 
DS traffic are expected to use whatever link capacity is available during lulls in 
the interactive loads. 
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When low-priority DS sessions span multiple links, the lulls in the interactive 
loads on all those links must be concurrent, or nearly so, for significant 
amounts of the D&S traffic to flow. If one link spanned by the session is heavily 
utilized, it sets a limit on the throughput of the low-priority session over its 
entire length, and may prevent the low-priority traffic from using otherwise 
available capacity on the other links. Path control intermediate routing nodes 
(PCIRNs) have some buffering capacity, and can usually handle short delays 
caused by bursts of interactive traffic on a link. For longer delays, however, the 
PCIRNs may have to reduce the flow on the low-priority session. 


The throughput between two DSUs may be increased by adding intermediate 

DSUs between them, so that low-priority DS sessions need not span so many 
links. Traffic is then able to flow over a particular session to an intermediate 

DSU while there is a lull on that session, even if the next “hop” to the destina- 
tion happens to be busy because of interactive traffic. When there is a lull on 
the next “hop,” the low-priority traffic can continue on its way. 


In other words, the more links spanned by a low-priority session, the smaller is 
the probability that there will be concurrent lulls on all of them. If any link is 
fully utilized by high-priority sessions, the flow on the low-priority session is 
slowed to a trickle. The use of intermediate DSUs that provide a store-and- 
forward function may reduce transit times and increase throughput compared to 
direct connections. 


Full-Function DS Networks 


Distribution Service Parameters 
DS is designed to provide a variety of types and levels of service. Originators 
may specify, as parameters on the verb by which they request a distribution, 
the levels of each type of service that the particular distribution requires. The 
values are included in the DS control information that flows through the 
network, and are used to condition the processing of the distribution at each 
DSU through which it flows. Each type of service requested is specified as a 
service parameter. 


Service parameters may be used to map particular types of DS traffic to partic- 
ular classes of service offered by the lower layers of SNA. They may be used 
to map different types of traffic to different routes through the DS network. Ata 
particular DSU, the service parameters may be used to determine how to 
handle a distribution--for example, whether it must be safe-stored on nonvola- 
tile storage. 


Implementations are allowed to select, according to architecturally defined 
rules, those portions of the DS architecture that they implement. The subsetting 
rules for the architecture are defined in Appendix C. Certain implementation 
choices may result in networks in which the DSUs offer different levels of capa- 
bility. The distribution service parameters are used to route distributions 
through only those DSUs capable of providing the requested service. 
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Service Parameters and Service Levels 
DS allows the specification of many different service parameters. Certain 
parameters are defined by the architecture; others may be defined by particular 
implementations. Up to 10 different service parameters may be carried in one 
distribution. 


Each service parameter is specified as a triplet. The triplet consists of 
e the parameter type--architecturally defined parameter types are 


priority 
protection 
capacity 
security 


¢ a comparison operator--the only comparison operator used by Format Set 2 
implementations is REQUIRE_LEVEL_GE. Format Set 1 implementations use an 
additional comparison operator, REQUIRE_SUPPORT_FOR. 


e a value--architecturally defined values vary by parameter type. They are 
discussed below. 


The combination of comparison operator and value describes the level of 
service required by the distribution. For example, the originator might request 
a certain level of service (priority, perhaps) as a minimum, but be quite happy if 
the distribution traveled at a higher level. This request would be expressed as 
a comparison operator of REQUIRE_LEVEL_GE and a value indicating the minimum 
level acceptable. 


The service parameters defined by the architecture are listed below, with a 
description of the comparison operators and values that may be specified for 
each. 


The priority service parameter allows an originator to specify the relative 
urgency of a particular distribution. DS favors higher priority distributions when 
there is contention for resources. For example, when distributions are queued 
for sending, the higher priority ones are serviced first. In some cases, higher 
DS-priority distributions may flow on (path control layer) virtual routes with 
higher transmission priority. In general, the higher the DS priority, the more 
quickly the distribution flows through the network. 


Any one of 16 different DATA priority values (DATA_1 through DATA_16, with 
DATA_16 being the highest priority) may be specified for ordinary distributions. 
Some implementations group DATA_1 through DATA_8 as DATALO and DATA_9 
through DATA_16 aS DATAHI. Above the DATA priority values are other values. In 
order of increasing priority, they are: CONTROL, which is used only for distrib- 
ution reports (i.e., it may not be specified on an agent’s request), and FAST, 
which is used for short, urgent types of messages. 


The protection service parameter is used to specify whether the distribution 
must be stored on nonvolatile storage while a DSU has responsibility for it. 
One of two values may be specified--LEVEL1 Or LEVEL2. LEVEL2 indicates that the 
distribution is safe-stored in nonvolatile storage; LEVEL1 indicates that safe- 
storage is not performed. 
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if the distribution needs to be protected in case of processor failure, the distrib- 
ution request specifies protection (REQUIRE_LEVEL_GE LEVEL2). If the distribution 
does not require this level of protection, the request specifies protection 
(REQUIRE_LEVEL_GE LEVEL‘). 


An implementation may choose the level of protection it provides. The advan- 
tage of requesting a less demanding level of protection for a distribution is that 
there may be more DSUs capable of providing it, and therefore more routing 
possibilities. In addition, the processing time within a DSU might be decreased. 


Some DSUs are able to handle only distributions whose DMU lengths are less 
than some specified maximum. The capacity service parameter allows DSUs 
with larger capacity to route large distributions around smaller-capacity DSUs 
that may not be able to handle them. Any route that passes through a size- 
limited DSU is appropriate only for distributions no larger than the maximum 
that the most limited DSU on the route can handle. This smallest maximum is 
the capacity of the route. 


The values that an originator may specify for the capacity parameter indicate 
the minimum capacity of the DSUs through which the distribution should be 
routed. Often, all distributions generated by a particular agent specify the same 
capacity. If the distributions vary widely in size the agent would specify an 
appropriate capacity for each distribution. 


The architecturally defined values are 


ZERO 


1MB (one megabyte) 
4MB 
146MB 


The capacity parameter indicates the size of the server object contained in the 
distribution. Although a distribution with no server object might specify a 
capacity requirement of ZERO, the distribution could still contain an agent object. 


The security service parameter is used to specify that the distribution is to be 
safeguarded from unauthorized access while it is being sent through the DS 
network. Two levels, LEVEL1 and LEVEL2, may be specified. LEVEL1 indicates that 
security is not required for the distribution. LEVEL2 indicates that DS should 
route the distribution only on sessions that are designated secure. (Typically, 
LU 6.2 session-level security would be used on such sessions.) When a distrib- 
ution specifying LEVEL2 as the security value is stored at a particular DSU, the 
DSU and its general server (see “Servers and Objects” on page 40) ensure its 
security. 


Default Service Levels 
Any or all of the service parameters may be omitted from the DMU, The archi- 
tecture defines a default service level for each parameter. A DSU processing a 
distribution uses the default service level for any parameter that is omitted from 
the DMU. The default values for each service parameter are given in 
Appendix G. 
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Combinations of Service Levels 
The DS architecture allows a level to be specified for each service parameter, 
independent of the levels specified for other parameters. Applications may 
choose either to specify service parameters independently on a per-distribution 
basis or to routinely use certain combinations of parameters. 


Uses of Distribution Service Parameters 
From the time DS accepts responsibility for a distribution request until the dis- 
tribution is delivered, the distribution service parameters may, and in some 
cases must, be used by all the DSUs to condition their processing of the distrib- 
ution. The effects of the service parameters are apparent both in the routing of 
the distribution and the local handling of it. 


Service Parameters in the Routing Table: Each entry in a DSU’s routing table 
includes the levels of service that the route is able to provide. Each distribution 
carries the levels of service specified by the originator. When the distribution is 
routed, the requested levels are compared to the levels available. 


To illustrate this process with a sample network, assume that a connection 
between EUR.PARSYS1 and US.CHISYS2 is to be reserved for small, high-priority 
traffic. Another connection, also reserved for small, high-priority traffic, is 
required between US.NYCSYS1 and US.CHISYS2. The resulting five-connection 
network appears as shown in Figure 15 on page 27. Notice that there are two 
connections between the same pair of DSUs, EUR.PARSYS1 and US.NYCSYS1. In 
order to distinguish between them, their identifiers must be qualified by a char- 
acterization of their service level capabilities. In this illustration, FAST and DATA 
are used. 
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Figure 15. Sample Network #3 Showing Different Routes for Different Priorities 


The routing table in EUR.PARSYS1 Contains entries as shown in Figure 16 on 
page 28. In addition to the connection identification of next-DSU name, the 
table entries include route service capabilities, queue identifiers, and the LU 
name and mode name (symbolized by “Fast” or “Slow”) that identify the group 
of sessions used by the connection. 


Each entry represents a route segment. The service capabilities describe the 
minimum capabilities that will be found along the route of which this particular 
route segment is part. Several route segments can share one queue. Several 
queues can share one connection. Generally, there is a one-to-one corre- 
spondence between a connection and the mode name of the session or group 
of sessions it uses. | 


When a distribution is to be routed, the combination of destination DSU and 
requested service parameters are used to scan the routing table in a serial 
fashion. The first entry for the destination DSU that provides acceptable service 
is used to identify the next-DSU queue into which the distribution is placed. 
After the distribution is placed in the next-DSU queue, a DS transaction 
program will retrieve it and send it on the connection to which that particular 
queue maps. 
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Figure 16. The Paris DSU’s Directory and Routing Table for Sample Network #3 


These entries do not represent a formal definition of what is included in the 
routing table. Implementations arrange their table structures in whatever way 
is most appropriate for them. In particular, the network-unique DSU names and 
LU names shown in the illustration are not required. Local values such as 
pointers and offsets may be used. 


The DSU name and the LU name need not be the same. For example, to facili- 
tate network changes, it may be desirable to give one DSU multiple DSU 
names, but it would still have only one LU name. When the same value is used 
for the DSU name and LU name, installation and operations complexities are 
reduced. 


Selecting Next DSU with Service Parameters: Notice the two entries for 
US.CHISYS2 in Figure 16. The first entry describes a route segment of a route 
with a priority capability of FAST connecting directly to the destination DSU. 
The second entry describes a route segment with a priority capability of DATA_1 
through DATA_16 connecting to an intermediate DSU. If Piaf requests FAST for a 
single destination distribution to Chase in Chicago, the distribution is routed 
directly to US.CHISYS2. If, on the other hand, Piaf requests a priority between 
DATA_1 and DATA_16, the distribution is routed via the intermediate DSU 
US.NYCSYS1. 


A multi-destination distribution sent from Piaf at EUR.PARSYS1 to US.NYCSYS1 and 
to Chase in Chicago is fanned out at the origin if priority FAST is specified, as 
shown earlier in Figure 9 on page 17. On the other hand, if priority DATA_4 is 
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specified, the fan-out occurs at the intermediate DSU. This comparison illus- 
trates how the use of direct sessions that bypass intermediate DSUs may 
shorten transit times but increase the amount of duplicate transmission. DS 
connections using sessions assigned to multi-link virtual routes should there- 
fore be used sparingly, except for high-priority traffic. The larger the object 
being distributed, the greater is the benefit of intermediate fan-out. 


Selecting a Session Using Service Parameters: In many cases, parallel (2 or 
more) sessions will exist between DSUs. The sessions will typically offer dif- 
ferent classes of service. DS uses the LU 6.2 mode name to distinguish 
between the various kinds of sessions. For example, at the basic LU 6.2 layers 
of SNA, the session to US.NYcSYs1 with mode name “Fast” would be assigned a 
higher transmission priority than the session with mode name "Slow.” DS 
would take advantage of the higher transmission priority by mapping a DS route 
of priority FAST to an LU 6.2 session with mode name “Fast.” 


Selecting Send Order Using Service Parameters: In some cases, only one 
session is available for a connection. Even when parallel sessions are avail- 
able, it is generally desirable to limit the number of sessions used, particularly 
for low-priority, high-volume traffic. With limited numbers of sessions, in times 
of heavy loads on the network, the DS distributions will build up in queues for 
whatever next-DSU they must be sent to. These queues are called next-DSU 
queues. 


The DS processes that access the routing table and put the distributions into 
next-DSU queues belong to the routing sublayer of DS. The processes that 
service the queues by sending the distributions out on the conversations belong 
to the distribution transport sublayer. The queues themselves can be viewed 
as straddling the protocol boundary of these two sublayers. Figure 17 on 

page 30 illustrates this. 
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Routing 
US.NYCSYS1 US.NYCSYS1 . US.CHISYS2 Sublayer 
slow queues fast queue fast queue 

Distribution 

Transport 

Sublayer 


EUR. PARSYS1 
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node with DSU 
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/-(US. CHISYS2-EUR. PARSYS1-FAST) | , 
/ Oe @Coeeeseeeceseeneecres eeeee (TPF2) e 


Figure 17. The Paris Section of Sample Network #3 Showing Two Queues for One Con- 
nection 


Managing the next-DSU queues is an important part of the DS function. 
Requests specifying the same priority are queued on a first-in, first-out basis. 
Requests of higher priority may be assigned to the same sessions but are sent 
before those of lower priority. 


One way this can be achieved is to maintain multiple queues for each con- 
nection and assign different priorities to separate queues. In the example 
shown in Figure 17, two queues exist for the DATA connection to US.NYCSYS1. 
The number suffix in the queue name represents the order in which the queues 
are serviced; that is, all the distributions in queue A1 are to be sent before any 
from queue A2. The routing table for EUR.PARSYS1 showing the next-DSU queue 
identifiers is given in Figure 18 on page 31. 


30 SNA/Distribution Services Reference 


PARIS 


USER DIRECTORY 


Destination) Destination 
User Name {DSU 


MFG.CHILD |US.CHISYS2 
MKT. NEFF US.NYCSYS1 
MKT. PIAF local 

OPS.CHASE |US.CHISYS2 


Routing Table 


Destination Route Segment Information 


DSU 
Route Service Parm Capabilities Next-|Connection _|Session(s) used 
DSU 
Prot— Queue|Next DSU- LU name-Mode name 
Priorityjection |Capacity| Security Connection Name 
Cl 


US. CHISYS2 LEVEL] LEVEL1 US.CHISYS2-FAST | US.CHISYS2-Fast 
US.CHISYS2 LEVEL2 LEVEL2 US.NYCSYSI-DATA |US.NYCSYS1-S1 ow 
US. CHISYS2 LEVEL2 LEVEL2 US.NYCSYSI-DATA |US.NYCSYS1-S1 ow 
US.NYCSYS1 LEVEL1 LEVEL1 US.NYCSYSI-FAST |US.NYCSYS1~-Fast 
US. NYCSYS1 LEVEL2 LEVEL2 US.NYCSYS1-DATA |US.NYCSYS1-S1ow 
US.NYCSYS1 LEVEL2 LEVEL2 US.NYCSYSI-DATA | US.NYCSYS1-S1 ow 


DSU name: EUR. PARSYS1 
LU name: EUR.PARSYS1 


Figure 18. The Paris DSU’s Routing Table with Two Queues for One Connection 


The connection and session information shown in Figure 18 are not truly 
needed in the routing table. The queue name alone would suffice. The 
required relationships to connections and groups of sessions could be estab- 
lished by various additional tables and pointers. The example illustrates how 
distributions with DATA_N priorities flow over sessions with a mode name of 
“slow,” which, in turn, can be assigned (at the path control level) to a virtual 
route with a transmission priority field (TPF) value of 0, the lowest of the three 
TPF values available. 


Implementation Alternatives: The above example shows one way of ordering 
the sending by priority. Various implementations might choose other ways, 
such as maintaining one queue but keeping the entries in it sorted by priority. 


Some implementations delay the decision of which connection to use for a dis- 
tribution. Distributions can be queued by routing table entry. The determi- 
nation of which connection should be used to service which queue can be 
deferred. In other words, the static relationships depicted in the routing tables 
illustrated here would be partly replaced by a dynamically determined relation- 
ship. The determination could be triggered by some event or condition. For 
dial-up networks, the determination might be triggered by the activation of the 
connection. 
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Local Handling of Distributions: Service parameters are also used to condition 
the DSU’s local handling of distributions. For example, if a distribution request 
specifies protection (REQUIRE_LEVEL_GE LEVEL2), the DSU is required to store it in 
nonvolatile storage before accepting responsibility for it. If a distribution 
request specifies security (REQUIRE_LEVEL_GE LEVEL2), the DSU may use additional 
parameters on the commands it issues to the server to access the distribution 
(see “Servers and Objects” on page 40 for a discussion of servers). Complete 
information on the actions taken by DSUs in response to specified service 
parameters is given in Appendix C. 


Sublayering in DS Networks 
DS is modeled as part of the transaction services layer of SNA, but is itself 
composed of sublayers. The notion of the distribution transport and routing 
sublayers was introduced in Figure 17 on page 30. Two more DS sublayers 
are defined: an uppermost sublayer that handles requests from agents, called 
the DS presentation sublayer, and a sublayer between DS presentation and 
routing that provides the directing process. Hence, DS consists of four sub- 
layers existing network wide, each sublayer existing in every DSU. The sub- 
layers are: 


DS Presentation 
Directing — 

Routing 

Distribution Transport 


Most implementations of DS employ queues at the boundaries between the 
presentation and directing sublayers, and between the routing and transport 
sublayers. There is less need for queuing between directing and routing, and it 
is not considered in this document. 


Processes Performed in the DS Sublayers 
The processes that perform the DS functions can be placed in, or in some 
cases across, the sublayers. Each DSU contains instances of the various proc- 
esses, provided by a collection of service transaction programs. A detailed 
model of the internal structure of a DSU is given in Chapter 3. 


e The processes in the DS presentation sublayer are called DS presentation 
services (PS).1 Agents interact with PS to use DS services. The following 
interactions are supported: 


— A Send _ Distribution verb initiates a distribution to one or more destina- 
tions. PS validates the request before accepting it. If PS accepts the 
request, it enqueues the distribution for processes in the directing sub- 
layer. 


— A Receive_Distribution verb provides the destination agent with access 
to the distribution. 


1 The DS presentation services (PS) sublayer is distinct from the SNA layer below the transaction services layer 
(in which DS resides), which is also called presentation services. The latter layer processes the LU 6.2 basic 
conversation verbs issued in DS, whereas DS PS processes DS verbs issued by application transaction pro- 
grams. In this book, ”PS,” unqualified, generally refers to the DS sublayer. 
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Other variations of the basic send and receive verbs provide agents with 
additional capabilities. The other verbs are discussed in “Agent Protocol 
Boundary Verbs” on page 55 and Appendix F. 


— Operations verbs provide access to enqueued distributions or to DS 
resources, such as the routing table, to display or change them. Oper- 
ations verbs also provide access to logged exception information. The 
operations verbs are described in “Operations” on page 68 and 
Appendix F. 


Verbs and parameters are passed across the protocol boundary to DS. 
Return codes are passed back indicating that the function has been com- 
pleted, successfully or not, as indicated by the code. 


The processes in the directing sublayer perform the following functions: 


— Determine the destination DSU names corresponding to destination 
user names and add them to the distribution--this is done at the origin 
of the distribution. 


— Determine the local queues and application program identifiers for dis- 
tributions at their destinations. 


— Change the destination DSU names for users whose destination DSU is 
the local one, but who are not, in fact, local users--the redirection case 
(see “Redirection” on page 35). 


Directing then invokes routing for nonlocal destinations. 


When a distribution is to be placed on more than one local queue, it is 
“fanned out” by directing. 


The processes in the routing sublayer perform the following functions: 


— Identify inbound distributions for which at least one destination DSU 
name is local. Directing is invoked for these destinations. 


— Use the routing table to select appropriate next-DSU queues for out- 
bound distributions. Routing may perform “fan-out” in the case where 
the distribution is placed on more than one queue. 


The processes in the distribution transport sublayer manage the communi- 
cation between DSUs to send a distribution from one DSU to the next. The 
queues into which the routing processes place distributions are accessed in 
predetermined order. This sublayer performs the encoding of the distrib- 
ution into a distribution message unit and handles the DS protocol for the 
transmission of the message unit. Protocols to exchange exception infor- 
mation are handled by this sublayer as well. LU 6.2 basic conversation 
verbs are issued and return codes and parameters are analyzed to accom- 
plish the transmission. 


The processes in the distribution transport sublayer invoke a facility known 
as a server to gain access to the server object when sending, and to store 
the received server object when receiving. The concepts of servers and 
server objects are explained in “Servers and Objects” on page 40. 


Processes in this sublayer manage the transfer of responsibility for a DMU. 
The sending DSU is responsible until the receiving DSU has signaled via a 
DS protocol that it has accepted responsibility. 
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Sublayer Diagrams 


All the sublayers of DS exist as part of the transaction services layer of SNA. 
The upper edge of DS is the DS agent protocol boundary (agent PB). This PB 
makes up only a part of the total PB offered to users by SNA services. The 
lower edge of DS is the basic conversation protocol boundary of LU 6.2. 


DS uses the basic conversation protocol boundary of LU 6.2 for sending and 
receiving its DMUs. DS shares the use of this PB with other service transaction 
programs. In the following diagrams, that protocol boundary is depicted as a 
solid line labeled LU 6.2 BCPB. It should not be confused with the mapped con- 
versation protocol boundary used by application transaction programs. A more 
detailed illustration of the structure of a DSU can be found in Chapter 3. 


As an example, once again assume that Piaf wants to send a low-priority dis- 
tribution (single destination) to Chase. The distribution is sent through 
US.NYCSYS1, Where only the routing function is involved. From a sublayering 
standpoint, the distribution is handled as shown in Figure 19. 


CHICAGO NEW YORK 


onreme nem meen emai, 


Presentation 


Directing 


Routing 


Distribution. 
Transport EUR. PARSYS1 


Lower Layers 
of SNA 


US. CHISYS2 


DTMU-A 
»»from MKT.PIAF at EUR.PARSYS1.. 
»-to OPS.CHASE at US.CHISYS2.. 


OTMU-B 
--from MKT.PIAF at EUR.PARSYS1.. 
»-to OPS.CHASE at US.CHISYS2... 


Figure 19. DS Sublayering Diagram--Intermediate Routing 
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Redirection 

Looking once again at sample network #2, particularly the directories in 
Figure 12 on page 20, assume that Neff in marketing is transferred to Chicago 
for a brief assignment, not long enough for the network administrators to want 
to change all the directories in the network. The redirection capability of the 
DSU in New York simplifies the required directory changes. Only the directo- 
ries at Neff’s old and new locations need be changed. Refer to Figure 20 and 
contrast the directory entries for MKT.NEFF with those in Figure 12 on page 20. 


CHICAGO NEW YORK PARIS 


USER DIRECTORY USER DIRECTORY USER DIRECTORY 


US. CHISYS2 
US.NYCSYS1 
local 

US. CHISYS2 


MFG.CHILD | local MFG.CHILD [US.CHISYS2 
MKT. NEFF local MKT. NEFF US. CHISYS2 
MKT.PIAF  |EUR.PARSYS1 MKT. PIAF EUR. PARSYS1 
OPS.CHASE | local OPS.CHASE |US.CHISYS2 


ROUTING TABLE ROUTING TABLE 


Destination| Connection 
DSU DSU (Next DSU) 


EUR. PARSYS1| US.NYCSYS1 EUR. PARSYS1/ EUR. PARSYS1 
US.NYCSYS1 | US.NYCSYS1 US.CHISYS2 |US.CHISYS2 


Destination| Connection 
(Next DSU) 


US. CHISYS2 US.NYCSYS1 EUR. PARSYS1 


Figure 20. Directories Illustrating Temporary Redirection 


Suppose that Piaf in Paris sends a distribution to MKT.NEFF. The DSU in Paris 
associates the destination DSU Us.Nycsys1 with MKT.NEFF. When DTMU-A 
arrives at US.NYCSYS1, the routing function there recognizes its own name, pre- 
sumes that it is the destination DSU, and passes the distribution up to the 
directing sublayer. The directing function accesses the user directory and 
finds, instead of local delivery information, another DSU name. It then replaces 
US.NYCSYS1 with the new name, US.CHISYS2, and passes the modified control 
information back down to routing. Routing then queues the distribution for 
US.CHISYS2. 


From a sublayering standpoint, the distribution is handled as shown in 

Figure 21 on page 36. The routing process invokes the directing process 
because the destination DSU name is local. Directing, after determining that 
the destination user is not local and after changing the destination DSU name, 
invokes routing. 
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Figure 21. DS Sublayering Diagram--Redirecting 


DTMU-A 
»ofrom MKT.PIAF at EUR. PARSYS1. 
«oto MKT.NEFF at US.NYCSYS1.. 


The redirection processing at the intermediate DSU, us.Nycsys1, should be com- 
pared to Figure 19 on page 34, which depicts pure routing at the intermediate 
DSU. 


In the example above, the redirection occurred at the most convenient point. 
Suppose, however, that Chase had moved to New York. A message from Piaf 
to him would be redirected at US.CHisysS2 back to Us.Nycsys1, the DSU through 
which it had just been routed. In networks of reasonable complexity, some 
occurrences of redirection may result in routing inefficiency. System adminis- 
trators must use care to keep this to a minimum. 


A DSU refers to its directory for any distribution whose destination list includes 
that DSU’s name. A DSU also refers to its directory if the destination list 
includes any of the DSU names in the DSU’s intervention list (see “The Inter- 
vention List” on page 40). In either case, redirection may result. 


Default Directing 
in large networks, the number of users makes it impractical to have an explicit 
entry for every user in every DSU’s directory. Instead, default “tokens” (the ~”*” 
in this documentation) can be used in place of parts of the user name; that is, 
either the DEN, or both the DGN and the DEN. The default token is like a wild 
card that can assume any value. User names for which a complete explicit 
match (that is, an exact match on both DGN and DEN) cannot be found are 
matched against the entries with explicit DGNs and * for DENs. User names 
that fail to match any DGN.* entry must by definition match the *.* entry, which is 
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simply the equivalent of “unable to find any match.” In other words, assuming 
that the directory is in collating sequence and the search algorithm is serial, 
the default tokens mean “none of the preceding” matched. 


Whatever DSU name is found at a default entry is used exactly the same way 
as the DSU name found at an explicit entry. That is, it is associated with the 
user name and is used for routing through the network. In some cases, the 
DSU name assigned by default will prove to be correct. In other cases, redi- 
rection will occur at the default DSU. In properly defined networks, the directo- 
ries at the default DSUs would have more explicit entries and, therefore, would 
be better able to direct distributions explicitly--that is, to direct them to the DSU 
where the user really is. 


The sample networks discussed earlier in this chapter have all had only four 
users, an extreme simplification employed to minimize table sizes in the exam- 
ples. To illustrate default directing, it is helpful to imagine a network with the 
same three DSUs, but serving more users. This network is only slightly larger 
than sample network #1. The following example is a complete network and not 
a fragment of a larger one. 


o CHICAGO o NEW YORK o PARIS 
Manufacturing Dept. Manufacturing Dept. Marketing Dept. 
Child North Piaf 
Marketing Dept. Marketing Dept. Operations Dept. 
Chapin | Neff Place 
Operations Dept. Nelson 
Chase Nesbit 
Chalk 


USER DIRECTORY USER DIRECTORY 


Destination|Destination 
User Name {DSU 


USER DIRECTORY 


Destination|Destination 
User Name {DSU 


Destination! Destination 
User Name jDSU 


MFG. CHILD 
MFG.* 
MKT. CHAPIN 


local 
US.NYCSYS1 
local 
US.NYCSYS1 
EUR. PARSYS1 
US.NYCSYS1 
local 
local 
EUR. PARSYS1 
error 
US.NYCSYS1 


MFG. CHILD 
MFG.NORTH 
MFG.* 

MKT. CHAPIN 
MKT. NEFF 
MKT.NELSON 
MKT. NESBIT 
MKT. PIAF 
MKT. * 

OPS. PLACE 


US. CHISYS2 
local 
error 
US. CHISYS2 
local 
local 
local 
EUR. PARSYS1 
error 
EUR. PARSYS1 
US. CHISYS2 
error 


Destination 
DSU 


US.NYCSYS1 
US.NYCSYS1 
local 
US.NYCSYS1 
US.CHISYS2 
local 


US. CHISYS2 
US.NYCSYS1 


ROUTING TABLE 


Connection 
(Next DSU) 


US.CHISYS2 |US.NYCSYS1 
US.NYCSYS1 | US.NYCSYS1 


EUR. PARSYS1 


US. CHISYS2 


US.NYCSYS1 


Figure 22. Sample Network #4--Directories with Default Entries 
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Default Routing 


Figure 22 depicts the directories for sample network #4. The directory at 
EUR.PARSYS1 contains default DEN entries for two DGNs, MKT and ops, pointing 
to US.NYCSYS1 and US.CHISYS2, respectively. The directory at US.NYCSYSs1 contains 
default DEN entries for all three DGNs. At Us.Nycsys1, however, MFG.* and MKT.* 
are errors. This means that the lists of explicit entries for those DGNs are 
exhaustive. If a DEN other than those listed occurs, it must be in error. The 
OPS.* points to US.CHISYS2 where the directory for ops is exhaustive. In this 
example, therefore, there is a complete set of DENs for every DGN in at least 
one DSU’s directory. 


The directory at EUR.PARSYS1 contains no explicit entry for the DGN mrc. Any 
user names beginning with MFG (or any DGN other than MkT or ops) will match 
the *.* entry at the bottom of the directory and be directed to Us.Nycsys1. The 
directory at EUR.PARSYS1 will never detect an invalid user name. The directory 
at US.CHISYS2 will detect invalid DENs within the ops DGN but any unrecognized 
DGNs will be directed to us.Nycsysi. Because the directory at us.Nycsys1 is the 
only one with a ** error entry, it is the only place at which completely invalid 
user names will be detected. 


Customers should define their networks so that every DGN has a complete set 
of explicit entries--that is, every DEN for that DGN--in a directory somewhere in 
the network. Similarly, at least one directory should contain a complete set of 
DGNs. Also, every DSU’s directory should be complete in the sense that any 

valid user name not explicitly matched will be redirected. Thus, the service can 
distribute from any DS-defined user to any other DS-defined user, always 
detecting invalid user names (for example, misspelled names) as such. 


Note that a ** default entry is different from an entry for omitted user names (as 
shown in Figure 7 on page 15). The latter matches destinations for which no 
user name was specified in the distribution request (i.e., node destinations). 
The former matches user destinations (those for which a user name was speci- 
fied in the request) that cannot be found in the local directory. 


In large networks, it is also impractical to maintain routing tables in every DSU 
with explicit entries for every other DSU. Default tokens can be used in the 
routing table in exactly the same way as in the directory. It would not be an 
error or even unusual to have an explicit entry in the directory that returned a 
destination DSU for which no explicit entry exists in the routing table. 


Looking again at sample network #3, Figure 17 on page 30, and the routing 
table in Figure 18 on page 31, it can be seen that the routing table has six 
entries, although EuR.PARSYS1 has only four queues for three sessions. The 
routing table could be shortened by the use of default routing tokens as shown 
in Figure 23 on page 39. 
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PARIS 


USER DIRECTORY 


Destination) Destination 
User Name /|DSU 


MFG.CHILD j|US.CHISYS2 
MKT. NEFF US.NYCSYS1 
MKT. PIAF local 

OPS.CHASE j|US.CHISYS2 


Routing Table 


Destination Route Segment Information 


DSU 
Route Service Parm Capabilities Next-|Connection _|Session(s) used 
DSU 


Prot- Queue} Next DSU- LU name—Mode name 
Priorityjection j|Capacity|Security Connection Name 


US. CHISYS2 LEVEL1 LEVEL1 US.CHISYS2-FAST |US.CHISYS2-Fast 

US.NYCSYS1 LEVEL1 LEVEL1 US.NYCSYSI-FAST |US.NYCSYS1-Fast 

US.* LEVEL2 LEVEL2 US.NYCSYS1-DATA |US.NYCSYS1-Slow 
LEVEL2 LEVEL2 US.NYCSYSI1-DATA |US.NYCSYS1-S1]ow 
any 


DSU name: EUR. PARSYS1 
LU name: EUR. PARSYS1 


Figure 23. Routing Table with Default Entries 


Notice that there is an explicit entry for fast priority traffic to US.CHISYs2, but no 
other explicit entries for US.CHISYs2. The Us.* entries will cause any distribution 
with an unrecognized REN (the low order part of the DSU name), and a priority 
Of DATA_1 to DATA_16 to be routed to US.NYcSYs1. The ** entry catches any unrec- 
ognized DSU names. Since this routing table is complete (i.e., any distribution 
for either of the other DSUs in the network will be handled by one of the 
entries), the ** entry maps to an error condition. Alternatively, the ** entry 
could be used to route all distributions destined for unrecognized DSU names 
elsewhere, just as a *.* entry in the directory causes distributions for unrecog- 
nized user names to be directed elsewhere. 


Network administrators should ensure that every routing table is complete in 
the sense that it contains either an explicit match or a default match for every 
destination DSU. 


Alternate Routing | 
Implementations may provide a mechanism to perform alternate routing when 
connections are unavailable. For example, the routing table might contain two 
entries for the same destination DSU and service parameter combination, with 
each entry identifying a different next-DSU. Assuming that the routing table is 
scanned in a serial fashion, the first entry would normally be matched, and all 
distributions would be sent to that next-DSU. If the connection to that next-DSU 
became unavailable, the DSU could mark its routing table entry unavailable. 
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The routing lookup process could then bypass that entry, and subsequent dis- 
tributions would be routed to the next-DSU named in the second entry. Since 
the specific contents of an implementation’s routing table are not defined by 
DS, such a mechanism is outside the scope of the architecture. 


The Intervention List 


A DSU may intervene in traffic destined for other DSUs. The intervention list 
specifies the names of other DSUs for which the DSU js to process traffic. 
These DSU names may or may not be the names of other DSUs in the network. 
A DSU name may appear in the intervention list of one or more DSUs. 


A DSU checks the intervention list when a distribution is received. The DSU 
invokes the directing process for traffic addressed to any of the DSU names in 
its intervention list, just as it does for traffic addressed to its real name. This 
feature can be used to facilitate network rearrangements. For example, when 
DSUs are combined, the resulting DSU would have the names of the eliminated 
DSUs in its intervention list. 


Another use of the intervention list is to facilitate “Big Brother/Little Brother’ 
implementations. For example, suppose that a particular implementation has 
only very limited resources to allocate to a directory and routing table, and that 
it supports only a small number of local users. The directory can be set up to 
define only the local users, and to route traffic (by default) for all other users to 
a partner DSU whose directory contains information for remote users. 


Since its directory would not contain information for remote users, redirection 
performed by the smaller DSU would be inefficient. An effective solution is to 
define the small implementation in the intervention list of the adjacent partner. 
The partner then processes all traffic destined for the smaller DSU as it does its 
own; the partner can perform redirection as necessary before sending traffic to 
the smaller DSU. 


Servers and Objects 


Introduction 


Large amounts of data that are to be distributed through the DS network are 
typically accessed via application programs called servers. Such data is 
encoded in the DTMU as the server object. 


When an agent issues a distribution request that is to contain a server object, it 
normally does not include the object itself in the request, but rather points to 
where the object can be found. The pointer to the object is stored by the DSU 
as part of the control information for the distribution. When the DSU is ready to 
send the distribution, it uses the server to read the object, one piece at a time. 
As each piece is retrieved, the DSU issues LU 6.2 basic conversation verbs to 
feed it into the network. The partner DSU receives the object, one piece ata 
time, and uses a server to store it away. The origin agent is responsible for 
specifying a server appropriate for the object to be distributed. 
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Server Names: The name of the server to be used at the origin and destination 
DSUs is specified as part of the request when the request refers to a server 
object. Server names are taken from the same name space as agent names. 


DS is unaware of an implementation’s internal packaging of servers. A single 
piece of implementation structure might be able to responsibly store and 
retrieve objects for a wide variety of server names. From the DS perspective, 
that single piece would be viewed as multiple servers. 


Origin Servers: DS uses the origin server to access the object for sending. No 
direct interaction takes place between the requesting agent and the origin 
server it specifies, either when the request is made or when the DTMU is sent. 
(The requesting agent stores the object using the origin server before issuing a 
distribution request to DS.) DS acts as the intermediary while processing the 
distribution. DS is unaware of interactions that take place between agents and 
servers when distribution requests are not involved. 


Destination Servers: The server name is put into the DTMU and flows through 
the network to all the destinations. Only one server name exists for the server 
object, no matter how many destinations are specified. The destination server 
is used at the destination DSU to store the object in application space (for 
example, a library shared by several users). 


Server Implementations: Servers may be of a unique kind implemented as part 
of the same application as the agent, or they may be general-purpose servers 
included in the supporting environment. 


Reversible Servers: A reversible server is one that can be invoked either for 
storing or retrieving. When instructed to retrieve an object that it has previ- 
ously stored, it retrieves the same byte stream it stored earlier. This does not 
mean that the byte stream must actually be stored in a byte-stream image, but 
it does mean that the server is able to reverse any transformations it might 
have performed upon the byte stream. Typically, servers would be reversible. 
An example of a nonreversible server would be one that printed hard copy. 


A DSU invokes a nonreversible server only if it has determined that the object 
will never need to be retrieved for forwarding or delivering multiple copies. 


Use of Servers: Figure 24 on page 42 gives a simple illustration of the inter- 
actions among the agent, server, and DSU. At some point before issuing a dis- 
tribution request, the agent interacts with the server to store an object (arrow 
1). The agent then issues a request to DS, specifying the server name (arrow 
2). When a connection is available to the next-DSU, DS invokes the server to 
read the server object (arrow 3), builds the DTMU, and sends it. 


The adjacent DSU receives the DTMU from its partner, invokes a server to store 
the object (arrow 4), and subsequently starts the destination agent. When the 
agent receives the distribution, which includes the destination server informa- 
tion (arrow 5), DS’s responsibility for the distribution is fulfilled. The agent may 
use the server information to access the object at a later time (arrow 6). 
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Figure 24. Simple Agent-Server-DSU Interaction 


DS considers the server object to be the byte stream passed across the server 
protocol boundary via the Read and Write verbs. DS numbers the bytes in this 
stream beginning at 1. A server object may be presented to the user or stored 
in safe storage in a form very different from that seen by DS, but these other 
forms are irrelevant to DS. For example, a 10-character text string might be 
compressed into six bytes when stored on disk, and encrypted into a 20-byte 
string for transmission. DS knows nothing of the 10-character text message, or 
the 6-byte compressed form stored on disk; it Knows only about a 20-byte 
server object. DS numbers the bytes in this object from 1 to 20. 


General and Specific Servers | 
Specific servers store and retrieve objects into and from users’ or applications’ 
private space. They are so named because they often perform some type of 
application-specific handling of the objects on which they operate; for example, 
a specific server might provide encryption and decryption of data, or it might 
perform specialized parsing of the objects passed to it. A specific server may 
be closely affiliated with one particular agent that uses it, or it may provide ser- 
vices to several agents. | | 


Specific servers may be sensitive to the contents of the byte stream passed to 
them. They may reject the object because it violates application-specific rules. 
They are not expected to cope with byte streams other than those defined for 
them. 


The general server is a server that DS uses to store server objects in DS’s 
storage space. It is a reversible server that is completely insensitive to the 
contents of the objects it stores. : 


DS perceives the objects it transports as no more than streams of bytes. 
Whenever a DSU is uncertain as to whether or not an object will have to be 
retrieved for forwarding or creating additional local copies, the DSU stores the 
object with a reversible server. If the DSU has available to it the destination 
server named in the distribution, and if that server is reversible, the DSU may 
use it to store the object without having to determine its role for the distribution. 
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In general, however, there will be distributions received with destination server 
names that the DSU does not have. (This implies that the DSU’s role for the 
distribution in question is purely intermediate, since it could not make any local 
deliveries.) In such cases, the DSU invokes a general server, totally ignoring 
the destination server name. In some implementations, the program invoked 
might be the same as that used to provide a specific server function. The name 
specified in the server protocol boundary verbs, however, would be that of the 
general server. To DS, therefore, it would be a different server. 


The general server is not sensitive to the contents of the byte stream passed to 
it. It cannot reject an object because of its contents. Typically, the space into 
which a general server stores its objects is associated with the system rather 
than a particular user or application. 


The general server’s name is used in server protocol boundary verbs but 
usually does not flow in DTMUs. The server name specified in the distribution 
request (which then flows in the DTMU) is usually a specific server name. The 
originating agent might, however, choose to specify the general server name 
for objects that have no significant internal structure and can conveniently be 
accessed by the destination agent as a serial byte stream. This implies that the 
space into which the general server stores objects is accessible to the origin 
and destination agents. 


The most general model of DS’s use of servers is illustrated in Figure 25 on 
page 44. In this model, the agent’s request (arrow 1) names a specific server 
to be used at the origin and destination. (Arrow 0 indicates the agent’s inter- 
action with the server before invoking DS.) The DSU copies the server object 
from the user’s (or agent’s) private space (arrow 2) into system space (arrow 
3), invoking the origin specific server to read the object and the general server 
to write it. Depending on parameters specified on the agent’s request, the DSU 
may or may not make this copy before returning control to the agent. Once the 
object has been copied into DS space by the general server, DS has responsi- 
bility for the distribution request. When a connection is available to send the 
distribution to the adjacent DSU, DS invokes the general server to read the 
object (arrow 4), builds the object into the DTMU, and sends it to the partner 
DSU. 


The partner DSU, upon receiving the DTMU, stores the server object into 
system (DS) storage space using the general server (arrow 5). If the DSU dis- 
covers, during the routing and directing process, that the distribution contains 
destinations local to the DSU, it copies the server object into the destination 
user’s (or agent’s) private storage space, invoking the general server to read 
the object (arrow 6) and the destination specific server (named in the distrib- 
ution) to write it (arrow 7). The destination server information is passed to the 
destination agent when it receives the distribution (arrow 8). The agent may 
then access the object using the specific server at a later time (arrow 9). 


At an intermediate node, the DSU receives the DTMU and stores the object 
using its general server. When the distribution is to be sent to the next DSU, 
the general server is invoked to retrieve the object for sending (Figure 26 on 
page 45). Since the DSU is not a destination for the distribution, the object is 
not copied to the specific server. 
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Figure 25. DS’s Use of Servers--General Model 


44 SNA/Distribution Services Reference 


NEW YORK 


a ee ee Agent PB Se a oe ee 
Presentation 
Directing 
General Routing 
Server 
=u (2) saescump Distribution 
Transport 
dq (1) ROoOMAKCALOCG | SKK SoSBSARRes 
US.NYCSYS1 
Se er ee Se ee =LU6)2 BOPB a ee 


Lower Layers 
of SNA 


cereeeanetiiiicesmsnadttiiineeses sents ee es me ee 


DTMU-A 


DTMU-B 
.. from MKT.PIAF at EUR.PARSYSI.. 
oto OPS.CHASE at US.CHISYS2... 
oe USING SEPVEN YYY.ecerceenes 


«from MKT.PIAF at EUR.PARSYS1I.. 
«oto OPS.CHASE at US.CHISYS2.. 
oe USING SEFVEN YVYY..cscceees 


Figure 26. The General Server at an Intermediate DSU 


Server Exceptions and Reporting 
Errors or exceptions may occur during any of the server operations that are 
performed as part of a distribution. The actions that DS takes and the excep- 
tion reports that it generates vary, depending on which server detects the 
exception. Specific servers are viewed as belonging to a using application (as 
are agents); the general server is viewed as belonging to DS. DS’s actions in 
response to an exception indication from a server reflect this notion. 


The most general model of DS’s use of servers is illustrated in Figure 25 on 
page 44. At the origin, the server object is copied from the origin specific 
server to the general server. At the destination, the object is copied from the 
general server to the destination specific server. These copy-making steps are 
referred to as auxiliary server operations. 


Auxiliary server operations are performed by DS as a service to the application 
program, prior to accepting responsibility for the request at the origin and after 
receiving the distribution at the destination. An exception that occurs during an 
auxiliary operation is reported via either a distribution report or a local server 
report, depending on whether the general or the specific server detects the 
exception. 
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An exception that involves DS or the general server is reported via a distrib- 
ution report. An exception that involves the specific server is reported to the 
local agent via a local server report. | 


At the origin, an exception detected by the specific server results in the delivery 
of a local server report to the local agent. The distribution is aborted (it could 
not be accepted by DS, since the server object could not be read). 


Once the object has been successfully copied to the general server at the origin 
and DS has accepted responsibility, any exceptions detected by the general 
server or DS are reported via distribution reports. Whether at an intermediate 
DSU or at the destination DSU, if the general server is unable to store the 
object upon receipt of the distribution, DS generates a report and sends it to the 
“report-to” destination specified by the originator (see “Distribution Reporting” 
on page 66). 


After the distribution has been received by the destination DSU and the server 
object has been successfully stored by the general server, an auxiliary opera- 
tion is performed to copy the object from the general server to the specific 
server (arrows 6 and 7 in Figure 25 on page 44). An exception during this 
operation is treated similarly to a failure during the auxiliary operation at the 
origin. If the exception involves DS or the general server, the exception is 
reported via a distribution report, and the distribution is terminated. If the 
exception involves the specific server, it is reported via a local server report to 
the local agent, and the distribution is delivered to the destination agent. 


_ The rules for reporting server exceptions reflect the notion that the specific 
server belongs to the application and the general server belongs to DS. Since 
a successful general-server operation means that DS has been able to trans- 
port the object through the network to the destination, a subsequent specific- 
server exception during the auxiliary server operation is deemed to be the 
responsibility of the application; it is thus reported locally to the destination 
agent on the Receive_Distribution verb. 


Early Acceptance of the Server Object : 
The essence of the reporting rules described above is that, at both the origin: 
and the destination, specific servers report exceptions to their agents, through 
DS. A specific server could have a variety of reasons for reporting to its agent. 
Even if the auxiliary operation is completely successful, a report might be 
required. 


A more general case is that of a partially successful operation. For example, 
the origin server might be unable to find all the items listed in the distribution 
request. If the origin server decides to send the distribution despite the 
missing items, it simply indicates to DS a normal completion of the server oper- 
ation. Only the server would know that the DTMU contains less than the 
Send _ Distribution verb requested. A responsible origin server would then 
report its partial failure to the origin agent via a local server report. Such a 
report has nothing to do with DS, except that DS delivers it to the agent across 
the agent protocol boundary. 
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At the destination as well, the specific server may encounter a partially suc- 
cessful operation. It may then choose whether or not to continue receiving the 
object. 


If it chooses to continue the operation, perhaps discarding whatever portions of 
the server object it cannot handle, DS is unaware of any abnormality. Only the 
server knows that the original Send Distribution is not completely successful. It 
is responsible for reporting this to the destination agent via a local server 
report. 


Alternatively, the specific server may choose to notify DS of the partially suc- 
cessful operation. It does so by returning an “early acceptance” indication 
(more precisely, a SPECIFIC_SERVER_EXCEPTION return code) followed by a server 
report. Upon receipt of this indication, DS continues processing the distribution 
normally, but terminates the auxiliary server operation. DS delivers the server 
report to the destination agent on the Receive Distribution verb. 


DS does not terminate the distribution because of a specific-server exception at 
the destination. Since DS has succeeded in transporting the distribution 
through the DS network, termination of the distribution because of an applica- 
tion (server) condition is not appropriate. DS continues processing the distrib- 
ution normally, and reports the specific-server exception to the local agent. 


‘Direct Fetch and Store 


Implementations may choose not to perform auxiliary server operations at the 
origin and destination. At the origin, the copy-making step from the specific 
server to the general server may be bypassed, so that the server object is not 
retrieved from the specific server until DS is ready to send the distribution into 
the network. This implementation elective is referred to as direct fetch. | 
Because of the potential reporting complexity, direct fetch is performed only for 
distributions that do not require fan-out at the origin. If a distribution requires 
origin fan-out, the origin DSU copies the server object to the general server 
before sending the distribution. . 


An implementation elective corresponding to direct fetch may be performed by 
a destination DSU. The destination DSU may choose to store an incoming 
object directly into an application’s (or user’s) private space as the DTMU is 
being received. This elective is referred to as direct store. 


The time during which a DTMU is being received at a DSU is referred to as 
receive time. The corresponding time at the sending DSU is referred to as send 
time. If any type of direct storing is to be performed, the command portion of 
the DTMU must be analyzed at receive time to determine the destination server 
name. If direct storing by a nonreversible server is to be performed, the desti- 
nation list must also be analyzed at receive time to determine whether or not 
all the destinations are local. This implies that both the routing and directing 
functions are at least partially performed while the DTMU is being received. 

For some DSUs, such an analysis might be difficult. For others, such as a DSU 
with only one user, it might be trivial. 
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If the destination server name is not supported by the DSU or, for nonreversible 
servers, if some of the destination users turn out not to be local, then direct 
storing is unachievable and the general server is invoked at receive time. 


Exception Handling with Direct Fetch and Store 
If direct fetch or direct store is used in place of an auxiliary operation, DS 
reports exceptions based on the same rules that apply to auxiliary operations. 
Specific-server exceptions are reported via local server reports; DS exceptions 
result in distribution reports. 


At the origin, an exception detected by the specific server results in a local 
server report; the distribution is aborted (it could not be accepted by DS, since 
the server object could not be obtained). An exception detected by DS results 
in a distribution report. | 


At the destination, an exception detected by DS results in the termination of the 
distribution and the generation of a distribution report. An exception detected 
by the specific server results in a local server report; the distribution is not ter- 
minated, but is delivered to the destination agent. 


The destination server returns an “early acceptance” indication (i.e., a 
SPECIFIC_SERVER_EXCEPTION return code) during direct store to inform DS that an 
exception has occurred and that the server does not wish to receive the 
remainder of the server object. The receiving DSU may then choose whether 
or not to inform the sending DSU. If the receiving DSU does not inform the 
sending DSU, the receiving DSU discards the server object as it is received 
rather than writing it to the server. Alternatively, the receiver may inform the 
sender via a Receiver Exception Message Unit. The two DSUs then use 
mid-MU restart protocols to continue the transfer of the remainder of the DTMU. 
If the remainder of the DTMU is transferred successfully, the destination DSU 
passes the server report to the destination agent as part of the 
Receive_Distribution verb. 


Server Access Descriptors and Specific Server Information 
If a specific-server object is to be included in the distribution, the originating 
agent includes the specific server name in the distribution request. The agent 
also includes one of two additional parameters: server_access or 
specific_server_info. The server_access parameter is used to specify a “pointer” 
to the server object. The specific_server_info parameter is used to specify 
instructions for the specific server to use to process the object prior to pre- 
senting it to DS. 


DS uses server_access or specific_server_info in much the same way, pre- 
senting the parameter to the specific server on the Initiate_Read verb. The 
server uses the parameter to return a stream of bytes (the object) to DS. If one 
or more of the destinations of the distribution are local to the origin DSU, 
however, DS may treat the server object differently depending on whether 
server_access or specific_server_info is supplied. 


The server_access parameter implies that the operation performed by the origin 


specific server is one of simple retrieval. If the distribution contains destina- 
tions local to the origin DSU, DS may choose to bypass the specific server 
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operation for those destinations, and merely supply the server_access param- 
eter to the destination agent on the Receive_Distribution verb. No specific 
server operation would be performed to store the specific server object on 
behalf of the local destinations. 


The specific_server_info parameter implies that the specific server performs 
some sort of application-specific processing of the object prior to presenting it 
to DS. If this parameter is specified, DS does not bypass the specific server 
operation for local destinations. DS invokes the specific server to “read” the 
object and perform the application-specific processing indicated by 
specific_server_info. (In some cases, the specific_server_info might contain all 
the data returned on the Read verb.) DS then invokes the specific server again 
to store the object for the local destinations. 


DS issues access-management verbs to control access to specific server 
objects described by server_access. No access-management verbs are used 
when specific_server_info is supplied in the distribution request. 


Agent vs. Server Objects 
Small amounts of data that the origin agent wishes to transfer directly to the 
destination agent are encoded in the agent object. Although the destination 
server is allowed read-only access to this data, the agent object is not deliv- 
ered directly to the destination server nor to general servers at intermediate 
DSUs. The server object is intended for larger objects, or objects that require 
application-specific processing by servers. The origin application program may 
use both the agent and server objects to achieve a “double-barreled” flow to 
the destination agent and server: the origin agent sends information to the des- 
tination agent in the agent object; the origin server sends information to the 
destination server in the server object. This is illustrated in Figure 27 on 
page 50. 
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Figure 27. Flow of Agent and Server Objects 


The Server Protocol Boundary 
| Servers are outside the DS architecture. Between the servers (there could be 
several) and the DS processes is a protocol boundary much like the agent pro- 
tocol boundary. Instead of requests and deliveries, the server protocol 
boundary has server objects and certain control information passed across it. 


The verbs that define the functions of passing the server object across the 
server protocol boundary are: 

e Initiate Read 

e Read 

¢ Terminate_Read 

e Initiate Write 

e Write 

e Terminate_Write 
If an exception occurs after an object has been completely stored (and 
Terminate_Write has been issued), the DSU may have to instruct the server to 
delete the object previously stored and back out any application-specific proc- 


essing performed during the storing operation. The DSU issues this instruction 
via the verb 
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e Backout_Server_Object 


Before DS accepts responsibility for distributing an object, it establishes 
“access rights” to prevent any rewriting or deletion of the object before DS is 
finished sending it out. Two access verbs provide this capability: 


e Assign _Read_ Access 


e Release Read_Access 


These access verbs are used by DS and the agent (originator or destination) to 
accomplish the transfer of responsibility for the server object, and to ensure 
that the object is maintained by the server while the agent or DS requires 
access to it. 


Once a server object has been created and the first read-access rights have 
been assigned, the object cannot be modified or deleted until all read-access 
rights have been released. The general server automatically deletes a server 
object in its space when the object’s read-access list becomes empty. The 
deletion action for specific server objects depends upon the specific server. 


DS uses two additional verbs to exchange information with the server regarding 
mid-MU restart of the server object: 


« Query_Last_Byte_ Received 


e Terminate_Restartability 


DS implementations capable of byte-count restart (see “Mid-MU Restart” on 
page 66) specify a restartability parameter on the Initiate_Read and 
Initiate_Write verbs to request that the server maintain a count of the number of 
bytes processed. The DSU queries the restart information by using the 
Query_Last_Byte Received verb. When the restart information is no longer 
needed, the DSU issues Terminate_Restartability to allow the server to discard 
it. 


DS and LU 6.2 


The Distribution Transport Sublayer 
The DS distribution transport sublayer consists of two transaction programs: 
DS Send and DS_Receive. These transaction programs issue LU 6.2 basic con- 
versation verbs to control the sending and receiving of DMUs over LU 6.2 con- 
versations. DS_Send is specialized to act as the sender of DMUs; DS_Receive 
is specialized to act as the receiver of DMUs. 


Each instance of DS_Send or DS_Receive acts as the endpoint of a single LU 
6.2 conversation. DS is designed to operate efficiently on a single-session con- 
nection, but to exploit parallel sessions if they are available. If the LU at which 
a DSU resides offers parallel sessions, the DSU may activate multiple instances 
of DS_Send and DS_Receive to make use of all the available sessions. 
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The DS transaction program that performs the directing and routing functions is 
called ”DS_Router_Director.” As the router-director operates on outbound dis- 
tributions, it places those distributions on next-DSU queues. For the purposes 
of this discussion, all the distributions that are awaiting transmission to a par- 
ticular LU using a particular LU 6.2 mode name may be viewed as residing on a 
single next-DSU queue for that LU name, mode name combination (see 
“Selecting Send Order Using Service Parameters” on page 29 for more about 
next-DSU queues). 


When DS_Router_Director places a distribution on a next-DSU queue, it checks 
that an instance of DS_Send is available to send the distribution to the partner 
DSU. Depending on the implementation, the number of sessions available for 
use by DS, and the number of instances of DS_Send already active, a new 
instance may or may not be started. Implementations monitor the number of 
active instances of DS_Send so that a session is available before activating an 
additional instance. 


When an instance of DS_Send is started locally (i.e., rather than via an Attach 
from DS _ Receive) for a particular LU name, mode name connection, it allocates 
a conversation with an instance of DS_Receive at the partner DSU. DS_Send 
then scans the next-DSU queue serving that LU name and mode name, and 
retrieves the highest-priority distribution from the queue. It encodes the distrib- 
ution as a DMU and sends it to DS_Receive. If it is able to successfully send 
the distribution and if DS_Receive accepts responsibility for it, DS_Send returns 
to the next-DSU queue, retrieves the next-highest-priority distribution, and con- 
tinues the process. 


DS_Send’s algorithm for selecting entries from the next-DSU queue means that 
distributions of higher priority are serviced before distributions of lower priority, 
and that distributions of the same priority are serviced in first-in, first-out (FIFO) 
order. DS Send continues sending distributions until the next-DSU queue is 
empty or until an exception causes the conversation to be deallocated. 


If multiple instances of DS Send are active for the same LU name, mode name 
combination, each one returns to the next-DSU queue independently to retrieve 
and ship the next waiting distribution. Figure 28 on page 53 illustrates this 
parallel-session scenario, with several instances of DS_Send serving the 
next-DSU queue for a connection. 


DS traffic flow is normally “push oriented.” In other words, the flow of DMUs is 
normally initiated by DS_ Send, when new traffic arrives ata DSU. Anew _ 
instance of DS_Send is started, if necessary; DS_Send then allocates a conver- 
sation and begins sending DMUs. 


it is also possible, however, for DS_Receive to “pull” traffic from a partner 
DS_Send. To do so, DS_Receive simply allocates a conversation to DS_Send 
and enters receive state. When DS_Send is placed in send state, it begins 
sending any traffic on its next-DSU queues. DS_Receive is responsible for 
soliciting traffic in this manner after it has reported a recoverable exception to 
DS_Send. The recoverable exception causes DS_Send to stop sending traffic; 
DS Receive starts the traffic flow again when the exception condition has been 
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remedied. DS_Receive might also choose to solicit traffic in other situations, 
such as when a switched connection is being used. 


DS_Send and DS Receive issue LU 6.2 basic conversation verbs according to 


precise protocols defined by the DS architecture. The protocols differ for 
Format Set 1 and Format Set 2 implementations. 
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Figure 28. Multiple Instances of DS_Send and DS_Receive 


DS’s Use of LU 6.2 Verbs -- Format Set 2 Implementations 
DS Format Set 2 implementations use a three-way flow to transfer responsibility 
for a high-integrity distribution from DS_ Send to DS_Receive. This protocol not 
only allows DS_Receive to confirm receipt of the DMU, but also allows the two 
cooperating DSUs to prevent the generation of duplicate transmissions in cases 
of network or processor failure. In simplified terms, the protocol works as 
follows. DS_Send transmits the distribution to DS Receive, and DS_ Receive 
returns a report confirming that it was received successfully. This report indi- 
cates DS_Receive’s acceptance of responsibility for the distribution. DS Send 
then discards its copy of the distribution, and sends a notification to 
DS_Receive that the distribution has been discarded. DS_Send may then 
retrieve and send another distribution, or it may deallocate the conversation. 


DS_ Send transmits the DMU to DS _ Receive by means of one or more LU 6.2 
Send_Data verbs. The number of Send_Data verbs required depends on the 
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size of the DMU and the size of the implementation’s buffers. DS_Receive 
issues Receive_And_Wait verbs to receive the DMU. When DS_Send has sent 
the last part of the DMU, it issues a Receive And_Wait verb to place 

DS_ Receive in send state. DS Receive then issues Send_Data to send a Com- 
pletion Report MU to DS Send. The Completion Report indicates that 

DS_ Receive has accepted responsibility for the distribution. DS Receive then 
returns to receive state by issuing Receive_And_Wait. DS_ Send issues 

Send_ Data to transmit a Purge Report MU, confirming that it has discarded its 
copy of the distribution, and may then begin sending the next distribution. 
When there are no more distributions to send, DS_Send issues Deallocate 
Type(FLUSH). 


The DS protocol allows for a wide range of throughput. Implementations may 
send varying amounts of traffic per conversation, depending on choices made 
by the sender and receiver. The protocol used varies slightly from that 
described above, depending on those choices. 


Levels of Integrity for Distributions 
Originators may request one of two levels of integrity for distributions--basic or 
high. The three-way flow is used for distributions that specify high integrity. 
For this type of distribution, DS_Send assigns a number to the DMU before 
beginning to send it to DS_Receive. This number, known as the MU_ID, is 
unique for the LU name, mode name combination on which the DMU is being 
sent. It is used for recovery of aborted transmissions and for the prevention of 
duplicate transmissions in case of network failures. A new MU_ID is used for 
each connection on which the distribution is sent. 


If the distribution specifies basic integrity, DS_ Send does not assign an MU_ID 
to the DMU before beginning transmission, and DS_Send and DS _ Receive do 

not exchange the Completion Report MU and the Purge Report MU. DS_Send 
transmits the DMU on a “best-effort” basis, and the handling of lost messages 
or duplicates is left to the using application (the agents). 


DS’s Use of LU 6.2 Verbs -- Format Set 1 Implementations 
Format Set 1 implementations use a protocol similar to that described above. 
However, instead of confirming the transmission of a DMU with the three-way 
flow, they use the LU 6.2 Confirm/Confirmed (two-way) flow. That is, after 
issuing the Send_Data verbs to transmit the DMU, DS_Send issues Confirm. If 
DS_Receive accepts the DMU, it replies with Confirmed. DS_Send then pro- 
ceeds with the next DMU. 


Format Set 1 implementations do not use the MU_ID for distributions. They use 
the Confirm/Confirmed protocol for all DMUs. 


The use of Confirm/Confirmed normally provides a reliable transfer of responsi- 
bility for the DMU from DS_Send to DS _ Receive. Some resource failure cases, 
however, may result in the generation of duplicate distributions. The use of the 
MU_ID and control MUs by Format Set 2 implementations allows these imple- 
mentations to detect and prevent duplicate transmissions. 
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A complete discussion of DS’s use of LU 6.2 basic conversation verbs is given 
in Chapter 2. 


Agent Protocol Boundary Verbs 


The agent protocol boundary allows use of two types of verbs: those for sending 
and receiving distributions and those for controlling operations. This section 
discusses the verbs used by agents to send and receive distributions. The 
verbs used by agents and operators to control traffic and perform network defi- 
nition are discussed in “Operations” on page 68. 


Verb Overview--Originating Distributions 
Agents originate a distribution by issuing a sequence of one or more of the fol- 
lowing verbs: 


¢ Send_Distribution initiates a distribution. It is issued either by an origin 
agent directly on behalf of a user, or by an origin agent performing higher- 
level function for the DSU. All sending sequences initiated by the origin 
agent include a Send_Distribution. 


e Query_Distribution Sending is issued by a sending agent to determine the 
current state of a distribution. In particular, the information returned on this 
verb informs the agent whether the sending DSU has completed any neces- 
sary auxiliary server operations. 


e Sending Sequence Completed is issued by a sending agent to complete 
the sending sequence for a high-integrity distribution. 


Verb Overview--Receiving Distributions and Reports 
Agents use the following verbs to receive distributions and reports from DS: 


¢« Receive Distribution is issued by the agent to receive a distribution. The 
distribution is returned to the agent in response to the Receive_Distribution 
verb. 


e Receive_Distribution Report is issued by an agent to receive a distribution 
report. 


e Receiving Sequence Completed is issued after the receiving agent has 
completed any application-specific processing necessary to store the 
received distribution. 


¢ Obtain _Local_Server_Report is issued by an agent to obtain a report gener- 
ated by a local specific server. 


Sending Sequences 
The sequence of verbs that an agent issues to originate a distribution is called 
a sending sequence. The verbs and parameters included in a sending 
sequence vary depending on the level of integrity requested for the distribution 
and the type of server object involved (if any). 


The originating agent initiates a sending sequence by issuing Send_Distribution. 
On the Send_Distribution verb, the agent includes all the control information for 
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the distribution. DS processes the Send_Distribution verb and returns control to 
the agent. 


The remainder of the sending sequence varies depending on the level of integ- 
rity requested for the distribution and the type of server object involved. If no 
specific-server object is involved (e.g., the distribution contained a general- 
server object or no server object at all), DS is able to take responsibility for the 
distribution immediately. It indicates this by returning sending state COMMITTED 
on the Send _ Distribution verb. If a specific-server object is involved, DS returns 
sending_state SPEC_SERVER_PENDING instead, because DS cannot “commit” itself 
to delivering the distribution until the specific-server operation to read in the 
server object is completed. The sending_state for the distribution is changed to 
COMMITTED after the server object has been successfully retrieved from the spe- 
cific server. 


if the sending state returned on Send _ Distribution is SPEC_SERVER_PENDING, the 
agent must query DS to find out when sending_state has been changed to com- 
MITTED. It does so by issuing Query_Distribution Sending. The sending state is 
returned to the agent in response to Query_Distribution Sending. For a high- 
integrity distribution, the originating agent is expected to finish the sending 
sequence by issuing Sending Sequence_Completed after DS has returned 
sending_state COMMITTED in response to either Send_Distribution or 
Query_Distribution Sending. Sending Sequence_Completed completes the 
high-integritv transfer of the distribution from the agent to DS. When the agent 
issues Sending Sequence_Completed, DS changes sending_state to COMPLETED, 
indicating that DS has responsibility for the distribution and that the sending 
sequence is complete. 


For a basic-integrity distribution, the agent does not issue 

Sending Sequence_Completed. When the specific server operation has been 
completed, the sending_state for the distribution is changed from 
SPEC_SERVER_PENDING to COMPLETED. The agent may issue 

Query_Distribution Sending to inquire about the state of the distribution. 


The agent supplies the distribution identification and includes it on each verb of 
the sending sequence. The distribution identification (origin DSU; origin user, if 
any; origin agent; date; and sequence number) uniquely identifies the distrib- 
ution. 


Sample Sending Sequences 
This section presents sample sending sequences for basic- and high-integrity 
distributions with various types of server objects. 
Basic-Integrity Distribution with No Server Object 


1. The agent issues Send_Distribution specifying 


¢ distribution_identification 
e integrity BASIC 


2. DS returns from Send_Distribution immediately with 


¢ return_code OK 
¢ sending_state COMPLETED 
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Since the distribution specifies basic integrity, the agent does not issue 
Sending Sequence_Completed. Responsibility for the distribution has been 
transferred to DS. 


Basic-Integrity Distribution with General-Server Object 


1. 


The agent writes the object into the general server’s space using the 
Initiate_Write, Write, and Terminate_Write verbs. 


. The agent allows DS to have access to the server object by issuing 


Assign Read Access (ps). Eventually the agent will issue 
Release _Read_Access (agent_name) to allow the general server to free the 
storage space. 


. The agent issues Send_Distribution specifying 


¢ distribution_identification 

° server GENERAL 

e server_access (access_descriptor) 
e integrity BASIC 


. DS prevents the server object from being prematurely deleted by issuing 


Assign _Read_Access (Ds). 


. DS returns from Send_Distribution with 


e return_code OK 
e sending state COMPLETED 


Responsibility for the distribution has been transferred to DS. The agent 
does not issue Sending Sequence_Completed. 


. The agent issues Release_Read_Access (Ds), since it can assume DS 


issued Assign _Read_Access for itself before returning control from 
Send_Distribution. | 


7. After sending the distribution, DS issues Release Read Access (Ds). 


Basic-Integrity Distribution with Specific-Server Object 


1. 


The agent stores the object using the specific server, and makes the object 
available to DS by issuing Assign _Read_Access (Ds) to the specific server. 


. The agent issues Send _Distribution specifying 


e distribution_identification 

e server (specific_server_name) 

e server_access (access_descriptor) 
¢ integrity BASIC 


. DS prevents the server object from being prematurely deleted by issuing 
_Assign_Read_ Access (DS) to the specific server. 


. DS returns from Send_Distribution with 


e return_code OK 
e sending state SPEC_SERVER_PENDING 


. DS performs an auxiliary operation to copy the server object from the spe- 


cific server to the general server. After acquiring access to the object in 
the general server, DS issues Release Read Access (Ds) to the specific 
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server. When the copy is completed, DS changes the sending state to com- 
PLETED. 


Alternatively, DS may perform direct fetch, deferring its invocation of the 
specific server until it sends the DTMU. The sending state is not changed 
to COMPLETED until after the object has been read from the specific server. 


. The agent does not issue Sending Sequence_Completed. It may issue 


Query_Distribution Sending to inquire about the state of the distribution. 


. The agent issues Release _Read_Access (Ds) to the specific server. 


. DS issues Release_Read_Access (Ds) to the appropriate server after the 


distribution has been sent. 


Basic-Integrity Distribution with Specific-Server Information 


1. 


The agent, by application-specific means, makes the server object (if any) 
available when needed. No access verbs are issued when specific server 
information is supplied instead of an explicit access descriptor (i.e., the 
server_access parameter) for a server object. 


. The agent issues Send_Distribution with 


¢ distribution_identification 

¢ server (specific_server_name) 

¢ specific_server_info (information) 
e integrity BASIC 


. DS returns control from Send_Distribution immediately with 


e return_code OK 
¢ sending state SPEC_SERVER_PENDING 


. DS performs an auxiliary server operation to read the specific server object 


from the specific server and write it to the general server. When the auxil- 
lary operation has completed, DS changes the sending state to COMPLETED. 
DS issues access management verbs to the general server, but not to the 
specific server. If DS performs direct fetch instead of an auxiliary operation, 
the sending state is not changed to COMPLETED until the direct fetch is com- 
pleted. 


. The agent does not issue Sending Sequence_Completed for the basic integ- 


rity distribution. The agent may issue Query_Distribution Sending to 
inquire about the state of the distribution. 


High-integrity Distribution with No Server Object 


1. 


The agent issues Send_Distribution specifying 


¢ distribution_identification 
e integrity HIGH 


2. DS returns from Send_Distribution immediately with 


¢ return_code OK 
¢ sending state COMMITTED 


3. The agent completes the transfer of responsibility for the distribution by 


issuing Sending Sequence_Completed. 
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4. 


DS returns from Sending Sequence Completed with 


e return_code OK 
¢ sending_state COMPLETED 


High-Integrity Distribution with General-Server Object 


1. 


9. 


The agent writes the object into the general server’s space using the 
Initiate _Write, Write, and Terminate_Write verbs. 


. The agent allows DS to have access to the server object by issuing 


Assign Read Access (Ds). Eventually, the agent will issue 
Release Read_ Access (agent_name) to allow the general server to free the 
storage space. 


. The agent issues Send_ Distribution specifying 


e distribution_identification 

e server GENERAL 

e server_access (access_descriptor) 
e integrity HIGH 


. DS prevents the server object from being prematurely deleted by issuing 


Assign_Read_Access (Ds). 


. DS returns from Send_Distribution with 


e return_code OK 
¢ sending state COMMITTED 


. The agent completes the transfer of responsibility for the distribution by 


issuing Sending Sequence_Completed. 


. DS returns from Sending Sequence_Completed with 


e return_code OK 
e sending state COMPLETED 


. The agent issues Release _Read_Access (Ds), since DS has issued 


Assign_Read_Access for itself. 


After sending the distribution, DS issues Release Read Access (Ds). 


High-integrity Distribution with Specific-Server Object 


1. 


The agent stores the object using the specific server, and makes the object 
available to DS by issuing Assign _Read_Access (Ds) to the specific server. 


. The agent issues Send_Distribution specifying 


¢ distribution_identification 

° server (specific_server_name) 

e server_access ({access_descriptor) . 
e integrity HIGH 


. DS prevents the server object from being prematurely deleted by issuing 


Assign_Read_Access (ps) to the specific server. 


. DS returns from Send_Distribution with 


e return_code OK 
e sending_state SPEC_SERVER_PENDING 
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5. DS performs an auxiliary operation to copy the server object from the spe- 
cific server to the general server. After acquiring access to the object in 
the general server, DS issues Release Read Access (Ds) to the specific 
server. When the copy is completed, DS changes the sending state to com- 
MITTED. 


Alternatively, DS may perform direct fetch, deferring its invocation of the 
specific server until it sends the DTMU. The sending state is not changed 
to COMMITTED until after the object has been read from the specific server. 


6. The agent determines the state of the distribution by issuing 
Query_Distribution Sending, specifying the distribution_identification. The 
agent may have to issue Query_Distribution Sending more than once, until 
sending_state is returned aS COMMITTED. 


7. When DS returns sending_state COMMITTED in response to 
Query_Distribution Sending, the agent completes the high-integrity transfer 
of responsibility by issuing Sending Sequence_Completed. 


8. DS returns from Sending_Sequence_Completed with 


¢ return_code OK 
e sending_state COMPLETED 


9. The agent issues Release_Read_Access (Ds) to the specific server. 


10. DS issues Release_Read_Access (Ds) to the appropriate server after the 
distribution has been sent. 


High-Integrity Distribution with Specific-Server Information 


1. The agent, by application-specific means, makes the server object (if any) 
available when needed. No access verbs are issued when specific server 
information is supplied instead of an explicit access descriptor for a server 
object. 


2. The agent issues Send_Distribution with 


¢ distribution_identification 

¢ server (specific_server_name) 

e specific_server_info (information) 
e integrity HIGH 


3. DS returns control from Send_Distribution immediately with 


e return_code OK 
e sending state SPEC_SERVER_PENDING 


4. DS performs an auxiliary server operation to read the specific server object 
from the specific server and write it to the general server. When the auxil- 
lary operation has completed, DS changes the sending state to COMMITTED. 
DS issues access management verbs to the general server, but not to the 
specific server. If DS performs direct fetch instead of an auxiliary operation, 
the sending state is not changed to COMMITTED until the direct fetch is com- 
pleted. 


5. The agent determines the state of the distribution by issuing 
Query_Distribution Sending, specifying the distribution_identification. The 
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agent may have to issue Query_Distribution Sending more than once, until 
sending_state is returned as COMMITTED. 


6. When DS returns sending state COMMITTED in response to 
Query_Distribution Sending, the agent completes the high-integrity transfer 
of responsibility by issuing Sending Sequence_Completed. 


7. DS returns from Sending Sequence_Completed with 


°« return_code OK 
¢ sending_state COMPLETED 


Receiving Sequences 
The sequence of verbs that an agent issues to receive a distribution is called a 
receiving sequence. The agent initiates a receiving sequence by issuing 
Receive_Distribution. DS passes the distribution to the agent in response to the 
Receive_Distribution verb. After performing any necessary handling and 
storage of the distribution, the agent issues Receiving Sequence_Completed. 
The Receiving Sequence_Completed verb completes the transfer of responsi- 
bility for the distribution from DS to the agent. 


Distribution reports are received using a similar receiving sequence. The agent 
issues Receive_Distribution_Report to obtain the distribution report. After 
storing the report, the agent issues Receiving Sequence_Completed to com- 
plete the transfer of responsibility. 


Sample Receiving Sequences 
The two-verb receiving sequence described above is used for both basic- and 
high-integrity distributions. Sample sequences are given below for the various 
types of server objects that may be involved in a distribution. Distribution 
reports are received using a sequence similar to that for a distribution with no 
server object. 


Distribution with No Server Object 


1. The agent issues Receive_Distribution. The agent specifies the identifier of 
the local queue from which the distribution is to be received. The agent 
may also specify the distribution_identification of a particular distribution to 
be received. If no distribution_identification is specified, the first entry in 
the queue is returned. 


2. DS returns from the Receive_Distribution with the control information (i.e., 
the DS command and the destination list) for the distribution and the agent 
object (if present). 


3. After performing the appropriate agent-specific actions for handling and 
storing the distribution, the agent issues Receiving Sequence_Completed. 
Responsibility for the distribution has been transferred to the receiving 
agent. 
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Distribution with General-Server Object 
1. The agent issues Receive Distribution specifying 


° queue_identifier 
e (optionally) distribution_identification 


2. DS returns from Receive_Distribution with the control information for the 
distribution (including the server access information). 


3. The agent issues Assign Read Access (agent_name) so that the object is 
not deleted prematurely. DS has previously issued Assign Read_Access 
(agent_name) to allow the agent to access the object. 


4. The agent issues Receiving Sequence_Completed to complete the transfer 
of responsibility. 


5. After the last copy of the distribution has been accepted by the agent (there 
could be multiple copies if destination fan-out has been performed), DS 
issues Release_Read_Access (agent_name), since DS can assume that the 
agent acquired access for itself before issuing 
Receiving Sequence_Completed. DS issues Release _Read_ Access (Ds) to 
notify the server that DS no longer requires access to the object. 


Distribution with Specific-Server Object 
1. The agent issues Receive_Distribution specifying 


¢ queue_identifier 
e (optionally) distribution_identification 


2. DS returns from Receive_Distribution with the control information for the 
distribution (including the server and access control information). DS has 
previously stored the object using the specific server. 


3. The agent issues Assign_Read_Access (agent_name) to acquire access to 
the object. DS has previously issued Assign _Read_ Access (agent_name) to 
allow the agent to access the object. 


4. The agent issues Receiving Sequence_Completed to complete the transfer 
of responsibility. 


5. After the last copy of the distribution has been accepted by the agent (there 
could be multiple copies if destination fan-out has been performed), DS 
issues Release_Read_Access (agent_name), since the agent has acquired 
access for itself. DS issues Release_Read_Access (Ds) to notify the server 
that DS no longer requires access to the object. 


Distribution with Specific-Server Information 


1. The agent issues Receive_Distribution specifying 


e queue_identifier 
¢ (optionally) distribution_identification 


2. DS returns from Receive_Distribution with the control information for the 
distribution (including specific_server_info). The specific server has previ- 
ously returned specific_server_info to DS in response to the 
Terminate_Write verb. 
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3. Access management verbs between the server and DS are not used when 
specific_server_info is returned instead of server_access. 


4. The agent issues Receiving Sequence_Completed to complete the transfer 
of responsibility. 


Exception Occurrences and Conditions 


In DS, exception occurrences include both conditions detected by various enti- 
ties at a DSU and intervention by operators. Most types of exceptions consist- 
ently produce particular observable conditions. 


Some types of exceptions have results that depend on timing conditions or con- 
currency of events. Such results are difficult to reproduce or even to detect. 

An example of a timing-dependent exception condition is the generation of 
duplicate distributions, which is possible in Format Set 1 implementations 
(Format Set 2 protocols allow implementations to prevent duplicate generation). 


DS exception conditions can be classified according to the layer in which they 
are detected or caused: 


e Application--agents and servers 
e DS--the DSU itself 
e LU 6.2 


Application Exceptions: Because of DS’s interaction with the application, DS is 
often aware of exception conditions that are detected or caused at the applica- 
tion layer. For example, a specific-server exception is considered, from the DS 
perspective, to be an exception at the application layer. If a server exception 
occurs while DS has responsibility for the distribution, DS may have to termi- 
nate the distribution (if told to do so by the server) and, perhaps, report the 
exception. 


DS Exceptions: Exception conditions detected by the DS layer fall into two cat- 
egories: 


e Exceptions detected in the verbs at the protocol boundaries 


e Exceptions detected, or operator intervention performed, after DS has 
accepted responsibility for the distribution. 


Exceptions are detected when the control information in the distribution cannot 
be reconciled with the information in a DSU’s tables, or when a resource fails. 
The exceptions that may be detected are 


¢ Routing exception 

e Directing exception 

e Format exception 

e Function not supported 
e System exception 

e Others 
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DSUs are required to perform certain minimal checks before accepting a dis- 
tribution. These checks are performed by DS presentation services before 
accepting a distribution from an agent across the agent protocol boundary, and 
by DS_ Receive before accepting a distribution from another DSU. Implementa- 
tions may choose to perform additional checks before accepting responsibility 
for distributions. The minimal set of required checks is described in 

Appendix C. 


See Appendix E for a complete list of the exceptions that may be detected by 
DS. 


LU 6.2 Exceptions: DS is aware of LU 6.2 exception conditions because DS 
must be prepared to accept a variety of responses to the LU 6.2 basic conver- 
sation verbs it issues. 


Exception Analysis 
Within the DSU, exception conditions may be detected at any of the four DS 
sublayers. As discussed above, an exception may originate within the DSU 
itself, in the application (the agent or server), or in the LU. The actions taken in 
response to a particular exception depend on the nature of the exception, the 
detector of the exception, and the scope of the exception. 


Detector: Any of four DS components may detect an exception: 


¢ DS presentation services: The exception is detected at the protocol 
boundary, while DS is processing a request from an agent. 


e DS_Router_Director: The exception is detected while DS is performing 
routing or directing functions. 


e DS_ Send: The exception is detected during the sending process. 

¢ DS Receive: The exception is detected during the receiving process. 
Responses to exceptions detected by DS presentation services are discussed in 
Appendix F. Responses to exceptions detected by other DS sublayers are dis- 
cussed in Appendix E. 
Scope: The scope of the exception condition may be any of the following: 

¢ The DSU: The condition affects all distributions at the DSU. 


e The connection: The condition affects all distributions being transmitted, or 
enqueued for transmission, on a certain connection (LU name, mode name). 


¢ The distribution copy: The condition affects one entire distribution copy and 
is unrelated to the destination list. 


¢ Some but not all destinations of the DMU: One or more destinations are 
directly affected by the exception, and one or more destinations are unaf- 
fected. 


e All destinations of the DMU: All destinations in the destination list are 
equally affected. This is different from a scope of the distribution copy only 
because the exception is per destination; all destinations happen to be 
affected. 


64 SNA/Distribution Services Reference 


e Local destinations only: The condition affects only destinations that are 
local to the DSu. 


« To be determined: A temporary condition has occurred that will not affect 
the distribution (or DSU) unless, after an implementation-defined number of 
retries has been attempted, the condition is deemed unrecoverable. 


As a result of implementation choices concerning role, electives, and optimiza- 
tions, as described in Appendix C, the exception information generated for a 
particular condition may vary slightly from one implementation to another. All 
implementations must be prepared to receive any of the valid report codes, as 
listed in Appendix E. 


Exception Handling 
Exception conditions detected by the DS presentation services sublayer are 
generally reported to the agent as returned parameters on a protocol boundary 
verb. For exception conditions detected by the routing, directing, or transport 
sublayers, exception handling procedures may include any of several actions: 


¢ Hold or release the next-DSU queue for the connection, so that transmission 
to the adjacent DSU is stopped or started. The hold condition placed on the 
next-DSU queue in response to an exception is termed an exception-hold. 
An exception-hold is released by operator action or by the initiation of a 
new instance of DS_Send. This contrasts with an operator-hold, which is 
placed on a distribution or a queue by an operator and is released only by 
operator action. 


¢ Perform MU-level reporting to inform the adjacent DSU, possibly termi- 
nating the DMU transmission. For DS_Send, this means sending a Sender 
Exception MU. For DS_Receive, this means sending a Receiver Exception 
MU. 


e Log the exception condition and notify the operator. 


¢ Abort the distribution, generate a distribution report describing the excep- 
tion condition, and send it to the report-to DSU or user specified in the dis- 
tribution. 


e Abort the distribution and return a specific-server report to the local agent. 
¢ Purge the distribution from the queue and purge the associated server 
object, if any. 


Any of these actions may be allowed, required, or precluded for a particular 
exception condition. The tables in Appendix E give the prescribed actions for 
exceptions detected at various points during the processing of a distribution. 


The DSU may perform any of several types of reporting in handling an excep- 
tion condition. The types of reporting performed by DS are 


e Local-agent reporting 

e MU-level reporting 

e Distribution reporting 

e Reporting to the local operator 


The types of reporting are described in more detail in Appendix E. 
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Mid-MU Restart 
Conversation failures or resource failures may occur during the transmission of 
a DTMU. Format Set 2 DS implementations are capable of restarting a failed 
DTMU at or near the point of failure, rather than having to retransmit the entire 
DTMU. The term for this capability is mid-MU restart. 


DS implementations provide two types of mid-MU restart. All Format Set 2 
implementations provide the capability to resume the transmission of a failed 
DTMU at the beginning of any of the highest-level structures following the agent 
object. Since the highest-level structures of a DTMU are sometimes referred to 
as LLIDs (because of the format of their encoding) this type of mid-MU restart is 
referred to as LLID restart. 


DS implementations may elect to provide an additional type of mid-MU restart 
called byte-count restart. A DSU that provides byte-count restart is capable of 
restarting a transmission at any byte position within the server object. 


To provide mid-MU restart, DSUs maintain knowledge of the high-level struc- 
tures of the DTMU already received. Implementers of byte-count restart, in con- 
junction with their servers, also maintain knowledge of the number of bytes of 
the server object already received. After a failure during the transmission of a 
DTMU, the receiver notifies the sender of the last structure it received and, 
optionally, of the last byte within the server object it received. The sender then 
continues the transmission based on that information. 


Further information on the mid-MU restart elective is given in the implementa- 
tion model in Chapter 3 and in Appendix C. 


Distribution Reporting 
In DS, two kinds of reports are returned to agents. One kind is the /ocal server 
report, which is generated by a specific server and given to the local agent by 
DS. Local-server reports inform the agent of an application-specific condition 
detected by the specific server. 


The other kind of report is the distribution report. The originator may specify, in 
the distribution request, that DS is to report on the condition of the distribution. 
For example, the originator may wish to be informed if DS is unable to deliver 
the distribution. Then, if an exception occurs, DS generates a report and 
delivers it to the report-to user (or DSU) named in the request. 


Distribution reporting may be requested for high-integrity distributions only (not 
for basic-integrity distributions). 


Distribution Report Message Units 
When distribution reports are sent through the network, DS encodes them as 
distribution report message units (DRMUs). The structure of a DRMU is shown 
in Figure 29 on page 67. Like a DTMU, a DRMU is introduced by a prefix and 
concluded by a suffix. The command contains the control information for the 
DRMU; the report information and SNA Condition Report describe the particular 
condition being reported. The report-to DSU/user is the DSU or user to which 
the report is being sent. 
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Prefix Command Report—To Report SNA Condition Suf fix 
DSU/User Information Report 


Figure 29. Distribution Report Message Unit Structure 


Service Parameters in the DRMU 
Like the DTMU, the DRMU carries service parameters that specify handling 
instructions for the distribution report. The parameters that may be specified in 
the DRMU are priority, protection, and security. There is no capacity parameter 
in the DRMU because the DRMU does not carry a server object. Any or all of 
the service parameters may be omitted from the DRMU. Default service levels 
are defined (see Appendix G) for each service parameter; DSUs processing the 
DRMU assume the default values for any parameters that are omitted. 


The originator of the distribution may specify report service parameters explic- 
itly in the distribution request. If report service parameters are specified, they 
are used as the service parameters in any DRMUs that are generated as part of 
the distribution. 


If the originator does not specify one or more of the report service parameters, 
a DSU that generates a report derives appropriate service parameters for the 
DRMU from the service parameters in the DTMU. For the protection and secu- 
rity parameters, the comparison operator and value derived are the same as 
those specified (either explicitly or via defaults) in the DTMU. For example, if 
the DTMU specified protection (REQUIRE_LEVEL_GE LEVEL2), the same parameter is 
used in the DRMU. 


For the priority service parameter, the value derived is either FAST or CONTROL. 
FAST is used if the DTMU specified FAST priority; CONTROL is used if the DTMU 
specified a DATA_N priority. CONTROL priority is used only in DRMUs; it may not 
be specified for the priority service parameter in a DTMU. 


The originator explicitly specifying a report service parameter for priority may 
specify a value of FAST, CONTROL, Or DATA_N. 


The Report-To Agent 
If the originating agent requests reporting on a distribution, it may specify the 
particular agent that is to be invoked to receive any distribution reports. If no 
report-to agent is specified, the agent invoked will be the same as the origin 
agent for the distribution. 


A report-to agent might be specified if the origin agent is not appropriate for 
receiving report information. For example, if a large number of destinations is 
specified, it might be desirable to have a special registry agent keep track of all 
the destinations, noting any errors encountered as reports are received. The 
originator could then get a consolidated report on the entire distribution. 
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Third-Party Reporting 


Operations 


Besides specifying the destination of the distribution, the originating agent may 
specify a third party to which all distribution reports are to be sent. This 
report-to party may be a user or a DSU. If no report-to user or DSU is speci- 
fied, reports are sent to the originating user or DSU. The originator specifying 
a third party for reporting should be reasonably confident that both the report-to 
DSU/user and a route to that DSU/user exist. 


The agent protocol boundary consists of two types of verbs. Verbs used to 
send and receive distributions are discussed in “Agent Protocol Boundary 
Verbs” on page 55. The architecture also defines operations verbs, which are 
used by agents and operators to manage DS traffic, manage DS connections, 
and maintain DSU definitions. The operations verbs are listed below. 


Managing Distributions 


Operations verbs permit agents to manage the distributions they have origi- 
nated or that have been queued for delivery to them. 


e List_Queues_ Containing Distribution returns the queue identifier of every 
queue that contains a copy of the specified distribution. 


e List_Queue Entries returns a list of the entries in a specified queue. 


e Get_Distribution_Info returns the control information for a specified distrib- 
ution. 


e Purge Queue Entry deletes a copy of a given entry from a given queue. 


e Hold Distribution Copy places a hold on a given copy of a given distribution 
on a given queue. 


e Release Distribution Copy releases the hold on a given copy of a given dis- 
tribution on a given queue. 


Managing Connections | 


Some DS implementations choose to exercise close control over the numbe 
and usage of a connection’s conversations (and underlying sessions). These 
verbs for managing connections are limited to operations agents; they are not 
meant to be issued by ordinary user agents. 


¢ List_Conversations lists the number of active conversations, both sending 
and receiving, for a connection, or an adjacent DSU, or for all adjacent 
DSUs. 


e List_Distributions Being Sent lists the IDs, including size of the yet-to-be 
sent portion of the server object, for all the distributions currently in the 
process of being sent on a connection, or on all connections to an adjacent 
DSU, or on all active connections. 


e List_Distributions Being Received lists the IDs and attributes, including the 
size of the already-received portion of the server object, for all distributions 
currently in the process of being received on a connection, or on all con- 
nections to an adjacent DSU, or on all active connections. 
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e List_Adjacent_DSUs lists selectively the DSUs adjacent to the local DSU. 
e List_Connections lists selectively the connections available to the DSU. 
e List_Control MU Queue lists the entries on a specified Control MU queue. 


¢ Start_Connection causes the appropriate number of DS_Send instances to 
be started. A parameter of this verb can be used to set the maximum 
number of instances of DS_Send that the DSU is allowed to start. 


* Reset_MU_ID_Registry allows an operator to resynchronize the MU_ID reg- 
istry for a connection. 


e Terminate _Connection causes every conversation on the connection to be 
stopped, either abruptly, or with a suspend, or as the MU in progress com- 
pletes. 


¢ Terminate_Conversation causes a particular conversation to be stopped, 
either abruptly, or with a suspend, or as the MU in progress completes. 


¢ Reroute_Distribution Copies causes all, or a selection of, the distribution 
copies found on a next-DSU queue to be reprocessed through the routing 
logic. Typically, the next-DSU queue will have been placed in the inactive 
state and the rerouting will queue the distributions for alternate next-DSUs. 


Maintaining DSU Definitions 
The DS system-definition verbs are used to create and maintain the various 
tables and miscellaneous values that constitute the definition of a particular 
DSU. The verbs are described below as they would be issued at the local oper- 
ations protocol boundary. 


The verbs used to support DSU definition are the following: 


e List_DSU_Data is used to display to the operator the value of a specified 
system parameter or the entries in a defined table. 


¢ Add _DSU_Data is used to add an entry containing one or more data param- 
eters to a data structure that can contain a list of entries. 


e Remove_DSU_Data is used to remove an entry containing one or more data 
parameters from a data structure that can contain a list of entries. 


¢ Modify DSU Data is used to change the value of one or more data parame- 
ters in a data structure. This verb is used for mandatory parameters of the 
DSU definition, such as the DSU name. It may also be used to modify a 
portion of an existing list entry. 


The DS data-structures that constitute the definition of a DSU and are main- 
tained by the above verbs are the following: 


e Directory 

¢« Routing table 

e Intervention list 

¢ DSU definition 

« Connection definitions 

e Next-DSU queue definitions 
e Agent list 

e Server list 
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e MU ID registry 


Managing Logs 


e Get_Exception_Log Entry returns a given exception logged by DS. 


e Get_Distribution Log Entry returns the message-unit control information 
logged by DS. 
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The DS Distribution Transport Sublayer 


This chapter describes DS’s use of LU 6.2 for Format Set 2 implementations. 
For a detailed model of DS’s use of LU 6.2, refer to Chapter 3. 


A brief introduction to the DS distribution transport sublayer is given in 
Chapter 1. This sublayer is composed of two transaction programs called 
DS_Send and DS Receive. Each instance of DS_Send or DS_Receive acts as 
the endpoint of a single LU 6.2 conversation. Parallel conversation usage is 
achieved via multiple instances of the transaction programs. 


In general, traffic is sent in both directions between a pair of DSUs. Instances 
of DS_Send at each DSU transmit distributions to instances of DS Receive at 
the partner. The sessions between the DSUs may be grouped according to 
mode name. Figure 30 shows two DSUs communicating over parallel sessions 
with two different mode names. Distributions are sent in only one direction on 
a given conversation, from DS_Send to DS_Receive. Control message units 
may flow in either direction on the conversation, from DS Send to DS_Receive 
or from DS_Receive to DS_Send. 


DSU: A 


| , DSU: B 
LU: A — -_ LU: B 
eof : 


SEN 


i} 
To DSU B, 


ay 


To DSU B, Mode X 


a 


To DSU A, 


To DSU A, Mode Y 


Figure 30. Parallel Session Usage Between Two DSUs 


To simplify the following discussion, Figure 31 on page 72 illustrates the main 
components of the distribution transport sublayer for a single direction of 
transfer on a single mode name (FAST). At DSU A, three instances of DS_Send 
are sending traffic on a connection to DSU B. The connection is identified by 
the combination of the name of the LU at which the partner DSU resides and 
the mode name of the conversations over which the DSUs communicate. 
‘Except for the Router-Director queue, separate instances of the data structures 
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shown in Figure 31 are maintained for each connection (i.e., each LU name, 
mode name pair). 


Data Structures at the Sending DSU 
All three instances of DS_Send obtain the distributions that they send to their 
partner from the same next-DSU queue. As discussed in Chapter 1, an imple- 
mentation might use one or more than one next-DSU queue for each con- 
nection. For the purposes of this discussion, assume all distributions awaiting 
transmission on a particular connection reside on a single queue. 


Besides the DMUs they transmit to the partner DSU, the DS_Send instances 
generate and transmit control MUs, which they use to inform the partner DSU 
about the status of DMUs. In the DS model in this document, control MUs are 
placed on a separate queue (the control-MU queue) when they are generated, 
and are transmitted by the first instance of DS_Send that becomes available. 
Whenever an instance of DS_Send enters send state, it checks the control-MU 
queue; if it finds entries there, it transmits them. If the control-MU queue is 
empty, DS_Send checks the next-DSU queue and transmits the highest-priority 
distribution it finds there. 


Next—DSU 
Queue for 
LU B, Mode FAST 


hel: 


Router—Director 
Queue 


| | Mid-MU 
Queue 


for LU A, 
Mode FAST 
Control MU 


Queue — 
for LU B, | | 
Mode FAST 


Control MU | | 
Queue for 


LU A, Mode FAST 


Conversations for Mode FAST 


Figure 31. Components of the DS Distribution Transport Sublayer 


Each instance of DS_Send transmits MUs over a single LU 6.2 conversation to a 
partner instance of DS Receive. DS Send is specialized to send DMUs; 

DS _ Receive is specialized to receive DMUs. Both DS_ Send and DS _ Receive 
send and receive various types of control MUs. 
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Data Structures at the Receiving DSU 
At the partner DSU, instances of DS_Receive (three, in the sample configuration 
in Figure 31) receive DMUs and control MUs from the corresponding instances 
of DS Send. After an instance of DS_ Receive successfully receives a DMU, it 
enqueues a control block representing the DMU on the router-director queue for 
further processing. 


The instances of DS_Receive share a control-MU queue for the connection, 
from which they transmit control MUs to the instances of DS_Send. Whenever 
an instance of DS_Receive enters send state, it obtains the first entry on the 
control MU queue and transmits it to DS_Send. It continues sending control 
Mus until the control-MU queue is empty, and then returns to receive state. 


The instances of DS_Receive also share a mid-MU restart queue for the con- 
nection. When DS_Receive begins receiving a DMU, it makes an entry for that 
DMU on the mid-MU restart queue. As DS_Receive receives the DMU, it 
updates its control block on the mid-MU restart queue. If an exception occurs 
and the DSUs decide to attempt mid-MU restart, DS_Receive informs DS_ Send 
of the point at which retransmission should begin based on the information in 
the mid-MU restart queue entry. When DS_Receive receives the continuation of 
the DMU, it finds the queue entry and continues updating it. Finally, when the 
DMU has been completely received, DS_Receive enqueues its control block on 
the router-director queue and removes it from the mid-MU restart queue. 


The MU_ID Registries 
Each DSU shown in Figure 31 on page 72 contains an MU _ID registry for the 
connection. The MU_ID registry tracks the state of each MU_ID currently in use 
by the DSU. An MU_ID is a number representing a particular piece of work in 
progress between the transport sublayers of the two DSUs. 


MU_IDs are used only when transmitting distributions that specify high integrity. 
Since no confirmation flows are exchanged for basic-integrity distributions, 
MU_IDs are not assigned to them. Basic-integrity distributions are transmitted 
on a best-effort basis; exceptions that occur during transmission may cause a 
basic-integrity distribution to be lost. 


If a distribution on the next-DSU queue specifies high integrity, it is assigned an 
MU_ID by the sender when it is first selected for transmission to the partner 
DSU. The MU_ID uniquely identifies the distribution until the two DSUs agree 
that they have finished (successfully or unsuccessfully) the piece of work 
represented by that MU_ID. At any time during the transmission of the distrib- 
ution, the MU_ID is in a particular state; when the DSUs finish using it, it is 
marked PURGED by both DSUs. Each DSU updates the state of the MU_ID as it 
processes the distribution, and as it receives control MUs containing informa- 
tion about the MU_ID from the partner. Refer to “Management of Message Unit 
IDs” on page 81 for more information about the use of MU_IDs and their states. 


Figure 31 on page 72 illustrates the transport sublayer for a single connection 
(LU name, mode name combination). Except for the router-director queue (of 
which there is typically only one per DSU), each DSU contains an instance of 
each data structure shown in Figure 31 for each connection (LU name, mode 
name pair) over which it communicates. 
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Defining Connections 
A DS connection is denied as the set of LU 6.2 sessions using a particular 
mode name over which a DSU communicates with another DSU. A connection 
is identified by both the LU name of the partner DSU and the mode name of the 
LU 6.2 sessions used to communicate with the partner. A connection may 
consist of one or more than one session. Multiple connections using different 
mode names may exist between two DSUs. 


LU 6.2 control operator verbs allow an operator to define to the LU the 
maximum number of sessions allowed for a given connection {by specifying the 
LU name and mode name), the contention-winner polarity of the sessions, and 
the number of sessions that are to be automatically activated by the LU. The 
DS operations verb, Start_Connection, allows the operator to define to the DSU 
the maximum number of instances of DS_Send that may be active on the con- 
nection. Since each active instance of DS_Send uses one session, and since 
typically each DSU uses its contention-winner sessions for sending, the value of 
the max_DS_ Sends parameter should normally be less than or equal to the 
number of contention-winner sessions defined for the DSU on the connection. 


DS Protocol for Transmitting Distributions 


DS_ Send and DS _ Receive issue LU 6.2 basic conversation verbs to transmit 
message units between DSUs. The message units they transmit are of two 
general types: distribution message units (DMUs) and control message units. 
(CMUs). Distribution message units contain distributions (or portions of distrib- 
utions); control message units contain information about DMUs and conversa- 
tion control information. . 


The information contained in DMUs typically travels through more than one 
DSU as it makes its way through the network. The information contained in 
CMuUs, however, is used strictly between adjacent DSUs to manage the traffic 
between those DSUs. 


The various types of DMUs sent from DS_Send to DS __ Receive are: 


¢ Distribution-Transport MU (DTMU): DS uses DTMUs to move distributions 
through the DS network. 


¢ Distribution-Report MU (DRMU): DS uses DRMUs to send distribution 
reports. 


- Distribution-Continuation MU (DCMU): DS uses DCMUs to resume trans- 
mission of suspended DTMUs. 


The various types of CMUs exchanged between DS Send and DS_Receive are 
listed below: 7 


e Sender-Exception MU (SEMU): The SEMU is sent from DS_Send to 
DS _Receive to inform DS_Receive that DS_Send has encountered an excep- 
tion condition. 


e Receiver-Exception MU (REMU): The REMU is sent from DS_Receive to 
DS_Send to inform DS_Send that DS_Receive has encountered an exception 
condition. 
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« Completion-Query MU (CQMU): The CQMU is sent from DS_ Send to 
DS_Receive to inquire about the state of an MU_ID. 


¢ Completion-Report MU (CRMU): The CRMU is sent from DS _ Receive to 
DS_Send to inform DS_Send of the state of an MU_ID or to control traffic 
flow on a conversation. 


e Purge-Report MU (PRMU): The PRMU is sent from DS_ Send to DS _ Receive 
to inform DS_Receive that the piece of work represented by a particular 
MU_ID is ended, and that the MU_ID has been marked PURGED. 


e Reset-Request MU (RRMU): The RRMU is sent from DS_Send to DS Receive 
to request that DS_Receive reinitialize its MU_ID registry. 


¢ Reset-Accepted MU (RAMU): The RAMU is sent from DS_ Receive to 
DS_Send after DS_Receive has reinitialized its MU_ID registry in response 
to an RRMU. 


Each of these control MUs will be discussed in detail in subsequent sections. 


Integrity of Distributions 
DS uses a three-step flow to transfer high-integrity DMUs from DS_Send to 
DS Receive. Figure 32 on page 76 gives a conceptual description of the mes- 
sages sent between the DSUs to accomplish a single transfer. 


After transmitting the DMU, the sender issues a “Responsibility-Transfer 
Requested” message. In the DS protocol, the suffix of the DMU carries the 
“Responsibility-Transfer Requested” semantics. By sending the suffix, DS_Send 
informs DS_Receive that it has sent the entire DMU, and requests that 
DS_Receive accept responsibility for it. 


Once the sender has issued “Responsibility-Transfer Requested,” it awaits 
notification as to whether the receiver has accepted or rejected the DMU. The 
sender takes no action (such as rerouting the distribution or sending a distrib- 
ution report) that might result in a duplicate DMU until it has been informed that 
the receiver has not accepted the DMU. 


If DS_Receive is able to complete the processing for the DMU, it returns a 
“Responsibility Accepted” message. “Responsibility-Accepted” is denoted in 
DS by the Completion-Report MU specifying that the MU_ID is COMPLETED. The 
CRMU (COMPLETED) notifies DS_Send to delete its copy of the distribution, since 
DS_Receive has safely received it. 


After deleting its copy of the distribution, DS_Send issues a ”“Responsibility- 
Relinquished” message to DS Receive. DS uses the Purge-Report MU to 
convey the “Responsibility-Relinquished” message. The PRMU informs 
DS_Receive that it need no longer retain explicit memory of the state of the 
MU_ID, because the unit of work represented by the MU_ID is finished. 


The three-step flow allows implementations to prevent the loss or duplication of 
distributions, because any of the three messages may be re-sent at any time. If 
the original transmission is lost, DS_Send may retry it (after querying 
DS_Receive to check that it has not been received). If the CRMU (COMPLETED) is 
lost, DS_Receive may send another (perhaps in response to a query from 
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DS Send). If the PRMU is lost, DS_Receive may re-issue the CRMU 
(COMPLETED) to solicit another PRMU. Each DSU retains the information 
required to re-send its messages until it is sure that the partner has received 
them. 


The three-step flow is used only for high-integrity distributions. No confirmation 
flows are exchanged for basic-integrity traffic. 


DS_SEND Conversation DS_RECEIVE 
Ge a re ee a Se a ee eee eR? 


(Data) >. 


Responsibility Transfer 
Requested (DMU suffix) ——>. 


.+—————- Responsibility Accepted 
(CRMU) 


Responsibility ‘ 
Relinquished (PRMU) ————>. 


Figure 32. The Three-Step Flow for High-Integrity Distributions 


Use of LU 6.2 Verbs--High Integrity 
Figure 33 on page 78 shows the sequence of LU 6.2 basic conversation verbs 
that DS_Send and DS_Receive issue to transfer a single DMU for a high- 
integrity distribution. In this example, DS_Send allocates the conversation; sub- 
sequently, it retrieves a distribution from the next-DSU queue. It encodes the 
distribution as a DMU and issues one or more Send_Data verbs to send the 
DMU to DS_ Receive. After sending the last portion of the DMU, DS_ Send 
issues Receive_And_Wait to place DS_Receive in send state. 


When DS_Receive is attached by DS_Send, it begins issuing Receive_And_Wait 
verbs to receive the DMU. It enqueues a control block representing the DMU 
on the mid-MU restart queue. As DS_Receive receives each buffer of data, it 
parses the data and updates the control block. When it receives the DMU 
suffix, DS_Receive enqueues the DMU control block on the router-director 
queue, removes it from the mid-MU restart queue, and starts 
DS_Router_Director. After DS_Receive successfully receives the DMU and per- 
forms the required receive-time checking (see Appendix C), it accepts respon- 
sibility for the DMU. 


When DS_Receive accepts responsibility for the DMU, it builds a Completion- 
Report MU (CRMU) specifying that the MU_ID is COMPLETED and enqueues it on 
the control-MU queue. When DS_Receive is placed in send state (as a result of 
DS_Send’s issuing Receive_And_Wait), it sends the CRMU (and all other control 
MuUs that are waiting on the queue). The CRMU (COMPLETED) informs DS_Send | 
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that DS_Receive has accepted responsibility for the DMU. When the control-MU 
queue is empty, DS_Receive issues Receive _And Wait to return to receive 
state. 


DS Send issues Receive_And_ Wait verbs to receive the control MUs from 

DS _ Receive. As it receives each control MU, it updates the MU_ID registry and 
the DMU control block to which the control MU refers. When it receives the 
CRMU (COMPLETED), it deletes the entry for the DMU from the next-DSU queue 
and deletes any server object associated with the DMU (if appropriate). After 
marking the MU_ID PURGED, it generates a Purge-Report MU (PRMU) and 
enqueues it on the control-MU queue. 


When DS_Send returns to send state (as a result of DS_Receive’s issuing 
Receive_And_ Wait), it sends any queued control MUs to DS _Receive, including 
the PRMU. When DS Receive receives the PRMU, it marks the MU_ID PURGED. 
After sending the PRMU, DS_Send may continue sending another DMU or deal- 
locate the conversation. 


Each time DS_Send enters send state (including the first time, when it begins 
executing) it sends all queued control MUs to DS_Receive. (This is not shown 
in Figure 33 on page 78. Before sending the DMU, DS_Send would send any 
control MUs on its queue.) When the control-MU queue is empty, DS Send 
selects a distribution and sends it. After sending the distribution, DS_ Send may 
again check the control-MU queue and send any new queued control MUs. 
Since control MUs, in general, allow the DSUs to resolve outstanding work 
items, each partner sends all its queued control MUs whenever possible. 
Before sending another DMU, however, DS_ Send enters receive state to allow 
DS_Receive to send its control MUs. 


Chapter 2. Overview of SNA/DS Protocols 77 


DS SEND Conversation —-DS_RECEIVE 


Allocate ————__—-_> . (attached) 
‘ 2 Receive_And_Wait 
Build DTMU 
Send_Data(Prefix,MU_ID=1)—>. : , 
r ; ry ea (DMU) 


6 ® 


‘ ‘ SS Receive And Wait 
Send Data (Suffix) ————. ‘ 


e 


—————»> (DMU Suffix) 


Receive_And Wait —-—-——>. . responsibility accepted 
; ; purge from Mid-MU restart queue 
ae : put on router-director queue 
‘ .+—————_ Receive_And_Wait 
; = (Send Indication) 


| = + Send_Data(Completion Report 
(Completion Report <«<———. ‘ MU, MU_ID=1 Completed) 
MU, MU_ID=1) | ; 

discard distribution ; ; 
mark MU_ID 1 Purged ; .+#—————_ Receive_And_Wait 


Receive_And Wait ——————>. 
(Send Indication) <«———. 


Send_Data (Purge Report ——> 
MU, MU_ID=1) > (Purge Report MU,MU_ID=1) 
ec ; Mark MU_ID 1 Purged 
 Send_Data(Prefix,MU_ID=2)—> : | 

(or Deallocate TYPE(FLUSH)) <+—_—__—Receive_And_Wait 
——_—————> (Prefix, MU_ID=2) 


(or Deallocate_ Normal) 


e e e e 2 se e e * 


Figure 33. Protocol for Transmitting High-integrity Distributions 


Use of LU 6.2 Verbs--Basic Integrity ! 
The verb protocol used to transfer basic-integrity DMUs is similar to that used 
for high-integrity DMUs. However, the DSUs do not exchange control MUs to 
confirm the transfer of basic-integrity traffic. After sending the suffix of a basic- 
integrity DMU, DS_Send discards the distribution and issues Receive_And_Wait 
to allow DS_Receive to send any queued control MUs. These control MUs 
might contain conversation control information (see “Throughput Control” on 
page 79) or information about other high-integrity DMUs, but DS_Receive does 
not generate a CRMU for the basic-integrity DMU it received from DS_Send. 
After sending any queued control MUs, DS_Receive issues Receive_And_Wait 
to return DS_Send to send state. DS_Send then continues with another DMU or 
deallocates the conversation. No PRMU is sent for the basic-integrity DMU. 


Figure 34 on page 79 illustrates a basic-integrity transfer. 
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DS_SEND Conversation DS_RECEIVE 
Reg a gape GP eg, ey yee am he ae aaa oy tog ee gs ag ep ye gem eran eng OTIS 


Allocate —-———————_.. ‘ (attached) 


: .+—————-_ Receive_And Wait 
Build DTMU . 
Send_Data(Prefix) ——-———~>. 
> (DMU) 


; ; .+—————-_ Receive_And Wait 
Send Data (Suffix) ————~. 
discard distribution ; > ©) (OMU Suffix) 
Receive And Wait ——————>. i responsibility accepted 

put on router-director queue 
.+—————_ Receive And Wait 
>) (Send Indication) 


; + Send Data (Control MUs, 
(Control MUs) —___——-, : if any): 


.+————_ Receive And Wait 


Receive And Wait ——————>. 
(Send Indication) <—————. 


Send Data(Prefix) ——~. 


(or Deallocate TYPE(FLUSH) ) .<+—_—— Receive_And_Wait 


Hs > (Prefix) 
(or Deal locate_Normal) 


Figure 34. Protocol for Transmitting Basic-Integrity Distributions 


Parallel Sessions 
The examples given above show all the exchanges between DS Send and 
DS _ Receive occurring on a single conversation. In general, two DSUs may 
communicate using parallel sessions. In this environment, the control MUs per- 
taining to a DMU are placed ona control-MU queue and sent by the first avail- 
able instance of DS_Send or DS_Receive. The CRMU and PRMU referring to a 
DMU may thus be sent on conversations different from the one on which the 
DMU was sent. In general, any control MU may flow on a conversation different 
from that of the DMU to which it refers. 


Throughput Control 
DS_Send may send an unlimited number of DMUs on a conversation before 
deallocating. If DS_Receive is unable to receive an unlimited number of DMUs, | 
it may instruct DS_Send to stop sending via the terminate_conversation flag. 


If DS_Receive returns a CRMU with the ferminate_conversation flag set ON, 
DS _ Send stops sending DMUs on the conversation. DS_Send may, however, 
continue sending control MUs until the control-MU queue is empty. When 
DS_ Send has no more control MUs to send, it deallocates the conversation. 
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DS Receive may use the terminate_conversation flag to achieve as low a level 
of throughput (DMUs received) on the conversation as it desires. For example, 
if DS_Receive is prepared to accept only one DMU per conversation, it sets 
terminate_conversation on in the first CRMU it returns to DS_Send. Figure 35 
on page 80 illustrates this scenario. DS_Send allocates the conversation and 
sends the first DMU to DS_Receive; DS_Receive returns the CRMU (COMPLETED) 
with terminate_conversation set ON. DS_Send then sends the PRMU and deallo- 


cates the conversation. 


DS_Receive may return the terminate_conversation indication in the first CRMU 
it sends to DS_Send or in any subsequent CRMU. 


DS_SEND 


Allocate 


Build DTMU ; 
Send_Data(Prefix,MU_ID=1)—>. 


Send Data (Suffix) —————>. 


Receive And Wait —————->. 


(Completion Report MU <—. 
MU_ID=1) 

discard distribution 

mark MU_ID 1 Purged 


Receive And Wait ————>. 
(Send Indication) <————. 


Send Data (Purge Report —> 
MU, MU_ID=1) 


Deallocate (TYPE(FLUSH)) —> 


Conversation 


DS_RECEIVE 


(attached) 


————> Receive _And_Wait 


————»> (DMU Suffix) 
responsibility accepted 
purge from Mid-MU restart queue 
put on router-director queue 
+ Recefve_And_Wait 
> __ (Send Indication) 


+—_—_—————Send_Data (Completion Report MU, 
MU_ID=1 Completed 
Terminate Conversation (YES)) 


Receive And Wait 


> (Purge Report MU MU_ID=1) 
: Mark MU_ID 1 Purged 


Receive_And Wait 


(Deal locate_Normal) 


Figure 35. Use of the Terminate_Conversation Flag--One DMU Sent per Conversation 


80 SNA/Distribution Services Reference 


Management of Message Unit IDs 


States and State Changes 
A high-integrity DMU being transmitted from an instance of DS_ Send to the 
partner instance of DS_Receive passes through several logical states. For 
example, while flowing over the LU 6.2 conversation, the MU is "Being- 
Transmitted.” In the period of time after it has been completely sent by 
DS_ Send but before the transfer of responsibility messages have been 
exchanged, the MU is ”“Pending-Transfer.” 


Since the sending and receiving DSUs use MU_IDs to correlate transmission- 
contro! and exception-handling information, it is the state of an MU_ID rather 
than the state of an MU that is of formal interest. An MU_ID represents a par- 
ticular piece of work in progress between the transport sublayers of the two 
DSUs. When a distribution is selected for processing by DS_Send, it is 
assigned a particular MU_ID; while it is being processed, the MU_ID uniquely 
identifies it. 


The two DSUs refer to the distribution using its MU_ID until they eventually 
agree to terminate the “unit of work” represented by that MU_!D; at that time, 
they both mark the MU_ID PuRGED. The purging of the MU_ID (i.e., the termi- 
nation of the “unit of work’), however, does not imply anything in particular 
about the distribution itself. The DSUs might decide to purge the MU_ID 
because the distribution has been successfully transferred to the receiver; 
because the distribution has failed and is being terminated; or because the dis- 
tribution will be retried, but will be assigned a different MU_ID. 


MU_IDs are used only for high-integrity distributions. Basic-integrity distrib- 
utions are not assigned MU_IDs. 


A DSU maintains a distinct MU_ID registry for each connection (i.e., the set of 
sessions it uses having the same LU name, mode name combination) on which 
it sends or receives traffic. Furthermore, the set of sequential MU_[Ds repres- 
ented in one MU_ID registry is used only for DMUs flowing in one direction. In 
other words, partner DSUs that send DMUs to one another for a particular 
mode name use two sets of MU_IDs to identify traffic on each mode name; one 
set for traffic flowing in one direction, the other set for traffic flowing in the 
other direction. An MU_ID, therefore, is unique for a particular direction of 
traffic flow on a particular connection. There is no inter-relationship between 
MU_ID registries for different connections, or between a DSU’s sending and 
receiving registries for a particular connection. 


This section presents an overview of the states of an MU_ID, and the possible 
state transitions that may occur at both DS_Send and DS Receive. The states 
used by DS_Send and DS _Receive to track MU_IDs are different, since DS_Send 
and DS_Receive encounter different circumstances while processing the DMU. 
For a formal description of the MU_ID state transitions at DS_Send and 

DS_ Receive, refer to “Formal Description of MU_ID State Transitions” on 

page 102. 
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States of MU_ IDs at DS_ Send 
The states of an MU_ID at DS_Send are: 


¢ NOT_ASSIGNED 


This is the “uninitialized” or “reset” state. No association eines peiwean 
the given MU_ID and any distribution. 


e IN TRANSIT 


This state is entered from NOT_ASSIGNED Or SUSPENDED. When entered from 
NOT_ASSIGNED state, it indicates that an MU_ID has been assigned to a par- 
ticular distribution. The transition from NOT_ASSIGNED to IN_TRANSIT marks 
the beginning of the MU transfer to the partner DSU, regardless of when the 
first Send Data verb is issued. When entered from SUSPENDED state, 

IN TRANSIT indicates that retransmission of the MU using the same MU_ID © 
has begun, with a DCMU. 


Any interruption of the transmission of a DMU that is detected by the 
sender is accompanied by a SEMU, regardless of whether any data has 
actually been sent to LU 6.2. In other words, any exception condition occur- 
ring on an MU_ID in IN_TRANSIT state is reported to the partner via a SEMU, 
regardless of whether any portion of the DMU has actually been trans- 
mitted. 7 


¢ TRANSFER_PENDING 


This state is entered from IN_TRANSIT. It indicates that the DMU suffix (which 
carries the “Responsibility-Transfer Requested” semantics) has been 
passed to LU 6.2 for transmission to the partner DSU, and that DS_Send 
awaits a CRMU (COMPLETED). The CRMU (COMPLETED) carries the “Responsi- 
bility Accepted” semantics. | 


DS Send may receive REMUs and unsuccessful CRMUs (e.g., CRMU feat 
NATED)) for an MU_ID that is in TRANSFER_PENDING state; DS_Send takes 
appropriate exception-handling actions based on the contents of the REMU 
or CRMU. 


© CQMU_PENDING 


This is primarily a system-failure restart state. Whenever an instance of 
DS_Send terminates abnormally (or is aborted), some number of MU_IDs 
might be left in states other than NOT_ASSIGNED, SUSPENDED, Or PURGED. The 
DSU issues CQMUs for such MU_IDs to solicit CRMUs, from which it learns 
the state of each MU_ID at the partner. The DSU may also issue a CQMU 
for an MU_ID if it has been awaiting a CRMU for an unacceptably long 
period of time, and assumes that the CRMU has been lost. 


While an MU_ID is in CQMU_PENDING state, DS_Send may receive CRMUs or 
REMuUs for it. DS_Send takes appropriate recovery actions based on the 
contents of the CRMU or REMU. 


¢ TERMINATION PENDING 


This exception-processing state is entered from IN_TRANSIT, and indicates 
that DS_Send has detected an exception and will not retry the transmission. 
DS_Send informs DS_Receive of the exception, and awaits a REMU or 
CRMU from DS_ Receive. After receiving the REMU or CRMU, DS_Send ter- 
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minates the distribution, generates a distribution report (DRMU) if appro- 
priate, marks the MU_ID PURGED, and sends a PRMU to DS Receive. 


¢ RETRY PENDING 


This is also an exception recovery state entered from IN TRANSIT. It indi- 
cates either that DS_Send detected an exception and intends to retransmit 
the MU, or that DS_Send received a Prog Error indication from DS_ Receive. 


Before continuing work on the DMU, DS_Send awaits a REMU or CRMU 
from DS_Receive. Based on the contents of the REMU or CRMU, DS_ Send 
may decide to restart the transmission (via a DCMU), retry the MU using a 
different MU_ID, or terminate the distribution and generate a distribution 
report (if appropriate). 


* SUSPENDED 


This state is entered from TRANSFER_PENDING, CQMU_PENDING or 
RETRY_PENDING. It indicates that a CRMU (SUSPENDED) was received, and that 
the transmission of the MU is to be resumed via a DCMU. 


e PURGED 


This state may be entered from any state other than NOT_ASSIGNED or 
IN_TRANSIT. It indicates that the DSUs have finished processing the “piece of 
work” represented by the MU_ID, and that the association between the 
MU_ID and the distribution has been broken. The MU_ID will not be reused 
until the Next-MU_!D-Counter for the connection is reset. PURGED implies 
nothing about the distribution itself. The distribution may have been suc- 
cessfully transferred; the distribution may have been terminated and a dis- 
tribution report generated (if appropriate); or the distribution may be left on 
the next-DSU queue to be transmitted again, using another MU_ID. 


MU_IDs in the PURGED state may be removed from the MU_ID registry. 


The typical progression of MU_ID states at DS_ Send in an exception-free sce- 
nario is NOT_ASSIGNED, IN_TRANSIT, TRANSFER_PENDING, PURGED. 


States of MU_IDs at DS_Receive 
| The states of an MU_ID at DS_Receive are: 
° NOT_RECEIVED | 
This is the “uninitialized” state for an MU_ID at DS Receive. 
¢ iN_TRANSIT | | 


This state is entered from NOT_RECEIVED when DS Receive receives the first 
part of a DTMU or DRMU, or from SUSPENDED when DS_Receive receives the 
first part of a DCMU. The IN_TRANSIT state indicates that the DMU is being _ 
received from the partner DSU. 


e SUSPENDED 


This state is entered from IN_TRANSIT when mid-MU restart capability is 
available for resuming transmission of the distribution and either: 


— Aretriable exception is detected by DS_Receive; or 


— A Prog Error indication is received from DS_Send. 
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The partially received distribution is held in a non-volatile mid-MU restart 
queue, and the partially received server object is maintained in the server. 


° TERMINATED 


This state may be entered from NOT_RECEIVED, IN_TRANSIT, Of SUSPENDED. 
From NOT_RECEIVED, it is entered when DS Receive receives a SEMU. From 
IN_TRANSIT, it is entered when DS _ Receive detects any non-retriable excep- 
tion, when DS_Receive detects a retriable exception but mid-MU restart is 
not appropriate, or when DS_Receive receives a Prog Error indication from 
DS Send and mid-MU restart is not appropriate. From SUSPENDED, it is 
entered when DS_Receive receives a SEMU indicating a non-retriable 
exception. 


The TERMINATED state indicates that both of the following are true: 


— DS_Receive will not accept a retransmission (DCMU) of the DMU using 
the same MU_ID. DS_Send will not reuse an MU_ID that DS_Receive 
has marked TERMINATED until the Next-MU_!ID-Counter for the connection 
is reset (and all MU_IDs are recycled). 


— D&_Send has not yet notified DS_Receive that it has purged the MU_ID. 


DS _ Receive may discard the partially received distribution and its server 
object, but must maintain the MU_ID and its TERMINATED status. 


* COMPLETED 


This state is entered from IN_TRANSIT. It indicates that DS_Receive has 
accepted responsibility for the distribution and that DS_Send may discard 
its copy. The COMPLETED state is entered after receiving a DMU’s suffix, 
which carries the ”“Responsibility-Transfer Requested” semantics. 


Before placing the MU_ID in COMPLETED state, DS_Receive must have suc- 
cessfully received and stored the DMU, performed at least the minimum 
receive-time checks, placed the distribution on the router-director queue, 
and scheduled DS_Router_Director. After placing the MU_ID in COMPLETED 
state, DS_Receive generates a CRMU. 


The receiving DSU may then forward the distribution to its next hop, deliver 
it locally, or generate a distribution report, as appropriate. However, the 
DSU must maintain the MU_ID and its COMPLETED state until the 
“Responsibility-Relinquished” signal is received from the partner (via a 
PRMU). 


¢ PURGED 


This state is entered from SUSPENDED, TERMINATED, Or COMPLETED when 
DS_Receive receives a PRMU. It indicates that DS_Send has placed the 
MU_ID in PuRGED state, and thus that DS_Send will not reuse the MU_ID 
until the Next-MU_!D-Counter for the connection is reset. Once an MU_ID 
has been placed in PURGED state, it may be aged out of the MU_ID registry. 


The typical progression of MU_ID states at DS_Receive in an exception-free 
scenario is NOT_RECEIVED, IN_TRANSIT, COMPLETED, PURGED. 
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MU_ID States--Active and Inactive 
Each MU _ID state used by DS_Send or DS_Receive may be categorized as 
either active or inactive. Active states require that DS_ Send or DS_Receive 
keep an explicit record of the MU_ID; inactive states do not require that explicit 
knowledge be kept. The initial and final states for both DS_ Send and 
DS_ Receive (i.e., NOT_ASSIGNED, NOT_RECEIVED and both PURGED states) are inac- 
tive; all other states are active. The MU_ID registry, therefore, contains an 
entry for each MU_ID in an active state. MU_IDs numbered above the current 
MU_ID counter are considered NOT_ASSIGNED Or NOT_RECEIVED. MU_IDs num- 
bered below the oldest MU_ID in the MU_ID registry are considered PURGED. 


MU_ID States and DSU Responsibility 
At any given time, exactly one DSU is responsible for a distribution. The 
responsible DSU must either deliver or forward the distribution, or terminate it 
and generate a distribution report (if appropriate). For DS Receive, the con- 
PLETED state indicates that the receiving DSU is responsible for the distribution; 
all other active states (IN TRANSIT, SUSPENDED, and TERMINATED) indicate that the 
sending DSU is responsible. DS Receive moves from not being responsible to 
being responsible at the same time that the MU_ID moves from IN_TRANSIT state 
to COMPLETED state. 


The IN_TRANSIT and SUSPENDED States clearly indicate that responsibility belongs 
to DS_Send. In general, however, responsibility is not as clear-cut for DS_Send 
as it is for DS_ Receive, because DS_Send cannot determine exactly when 

DS _ Receive accepts responsibility. For example, the MU_ID at DS_Send moves 
from IN_TRANSIT state to TRANSFER_PENDING State before the MU_ID at 

DS Receive moves from IN_TRANSIT state to COMPLETED state, because buffering 
and transmission of the DMU suffix by the underlying SNA layers take a certain 
amount of time. While the MU_ID at DS_Receive is IN_TRANSIT, DS_Send is 
responsible; immediately after DS_Receive changes the MU_!ID to COMPLETED, 
DS_Send is not responsible. In both cases, the MU_ID at DS_Send is in 
TRANSFER_PENDING State. 


The active states at DS_Send that have a ”responsibility unclear” connotation 
are TRANSFER_PENDING, TERMINATION_PENDING, RETRY_PENDING, and CQMU_PENDING. 
DS_Send moves to “not responsible” only when a “Responsibility Accepted” 
message is received from DS_Receive in the form of a CRMU (COMPLETED). 
Upon receipt of this message, DS_Send immediately discards the distribution 
and places the MU_ID in PuRGED state. If DS_Receive returns any other type of 
REMU or CRMU, DS_Send retains responsibility and responds to the MU_ID 
state indicated by the REMU or CRMU. 


DS _ Send uses the MU_ID state to record its intentions for handling the distrib- 
ution. For example, RETRY_PENDING and TERMINATION PENDING both indicate that 
an exception has occurred. RETRY_PENDING indicates that DS_Send intends to 
retry the transmission (either by sending a DCMU or by assigning a new MU_ID 
and retransmitting from the beginning). TERMINATION_PENDING indicates that 
DS _ Send will not retry the transmission, but intends to terminate it. 


Before carrying out its intentions, however, DS_Send awaits a control MU 


(REMU or CRMU) from DS_Receive. DS_ Send thus is aware of the MU_ID state 
at DS_Receive, and avoids inappropriate recovery actions. 
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MU_ID Instance Numbers 
DSUs using mid-MU restart capability may transmit one or more DCMUs to 
complete the transmission of a DTMU. Since the DTMU and related DCMUs 
carry the same MU_ID, DS_Send places an instance number in each DMU. The 
instance number is set to 1 in the DTMU, and is incremented each time a 
DCMU is sent. The instance numbers allow DS_Send and DS _ Receive to ignore 
contro! MUs that apply to previously sent DMUs. 


DS_Send is responsible for storing the current instance number for each MU_ID 
and transmitting it in DMUs, SEMUs, and CQMUs. PRMUs do not carry instance 
numbers. If DS_Send receives a control MU containing an instance number 
less than the instance number currently in use for the MU_ID, it discards the 
control MU. 


DS_Receive examines the instance number in each MU (DMU or control MU) it 
receives. If the instance number is greater than or equal to the current 
instance number in use for the MU_ID, DS_Receive processes the MU normally; 
if the instance number is less than the current instance number DS_Receive 
discards the MU. If the instance number is greater than the current instance 
number in use for the MU_ID, DS_Receive updates the current instance number 
to match the received instance number. DS_Receive returns the current 
instance number in each control MU (REMU or CRMU) that it sends to 
DS_Send. 


Removing MU_IDs from the MU_ID registry 
Once an MU_ID is marked PuRGED, the DSUs need no longer keep an explicit 
entry for it in their MU_ID registries. However, an MU_ID may be removed from 
the registry only if all MU_IDs numbered below it have been marked PURGED (or 
have been previously removed from the registry). This method of removal 
allows the DSUs to keep track of the MU_IDs they have successfully transferred 
and to detect MUs that may have been lost. 


For example, the receiver might find that its oldest MU_ID entry is NOT_RECEIVED, 
but that several higher-numbered entries have been marked PURGED. It might 
then assume that an MU has been lost, and issue a CRMU for the NOT_RECEIVED 
MU_ID to solicit its transmission. Refer to “Lost Messages” on page 97 fora 
further discussion of the mechanisms used to solicit MUs. 


The MU_ID registry 
The MU_ID registry may be viewed as a sliding window into the MU_ID space. 
The following example shows a registry for an n-session connection at 
DS_Receive. 
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Figure 36. The MU_ID Registry at DS_Receive for a Multiple-session Connection 


The lowest numbered entries in the registry would typically be marked PURGED, 
representing MU_IDs on which processing has been completed but which have 
not yet been “aged out” of the registry. Above those entries would be entries 
for some number of MU_IDs that are currently being processed. These MU_IDs 
might be in any state, active or inactive. For example, MU_ID x might be con- 
PLETED. MU_ID x+17, perhaps representing a shorter DMU, might already be 
PURGED, and MU_ID x+2 might be IN_TRANSIT. 


Above the entries for the MU_IDs currently being processed are entries for 
MU_IDs that are NOT_RECEIVED. If n parallel sessions are active for the con- 
nection, the receiver is prepared to receive any MU_ID up to n higher than the 
highest active or purged entry. If an MU_ID higher than that is received, it indi- 
cates that an MU_ID in the ”next-expected” range has been lost. 


At the top of the registry are n entries representing a “space-running-out” area. 
If DS_Receive receives an MU_ID in the “space-running-out” range, it rejects 
the DMU and marks the MU_ID TERMINATED. The exception information returned 
to DS_Send indicates that the DMU was not accepted because the registry is 
out of space. 


The most common cause of an “out-of-space” condition at DS_Receive is that a 
very old MU_ID remains active instead of being PURGED. Perhaps a PRMU was 
lost, leaving the MU_ID COMPLETED rather than PURGED, or perhaps the MU_ID is 
SUSPENDED and has not been resumed because of higher-priority traffic. Since 
the registry at DS_Receive must maintain a contiguous block of MU_ID values, 
and since only PURGED MU_IDs may be dropped from the bottom of the registry, 
an old MU_ID can prevent the registry from sliding up the MU_ID space to 
include higher values. The solution to this problem is for DS_Send to stop 
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transmitting distributions and take whatever actions are necessary to move the 
old MU_ID into PURGED state. 


Whenever DS_ Receive detects the “registry-running-out-of-space” condition, it 
issues CRMUs for its oldest active or NOT_RECEIVED MU _IDs. If these MU_IDs 
are in SUSPENDED state, DS_Receive either converts them to TERMINATED (and 
recovers the server object and partially received distribution resources) before 
issuing the CRMU or notifies the operator of the condition and requests inter- 
vention. 


If DS Send receives a REMU indicating a “registry-full” condition followed by 
CRMU (SUSPENDED) messages, and has distributions with higher priority than 
those specified by the CRMUs, it purges the SUSPENDED MU _IDs, issues PRMUs 
for them, and retries the distributions later with new MU_IDs. 


Synchronization of MU_ID Registries at Sender and Receiver 
In order for a sender and a receiver to manage the traffic being transmitted 
between them, their MU_ID registries must be synchronized. That is, assuming 
there are no DMUs to transmit at a given time, the next MU_ID to be used by 
the sender should match the next MU_ID expected by the receiver. The sender 
is responsible for initiating a resynchronization protocol when the “next-MU_ ID” 
values need to be reset. Both sender and receiver maintain a date/time stamp 
that indicates the “time of last reset” of their MU_ID registries. 


The sender initiates an MU_ID resynchronization when a connection is first 
established between two DSUs. The initial conversation on the connection may 
be allocated by either sender or receiver, but DS_Send always initiates the 
resynchronization sequence. The sender also performs resynchronization when 
it has used all the allowed values in its MU_ID registry. In addition, the sender 
may initiate resynchronization in response to operator action, or if it determines 
that an exception has caused its registry to be out of synchronization with that 
of the receiver (perhaps indicated by different “time-of-last-reset” values at 
sender and receiver). 


When the sender wishes to request re-initialization of the receiver’s MU_ID reg- 
istry, it stops transmitting DMUs on the connection. The sender then checks 
that each MU_ID in its (the sender’s) MU_ID registry is in an inactive state (i.e., 
in either NOT_ASSIGNED Or PURGED state). 


In the case of a normal resynchronization (i.e., DS_Send has not detected an 
“out-of-synch” condition), DS_Send follows normal protocols to move active 
MU_IDs to PuRGED state. If DS_Send has detected an “out-of-synch” condition, it 
notifies operations. Operations then decides on the appropriate action to take 
for each active MU_ID. For MU_IDs in a “responsibility-unclear” state. oper- 
ations would typically change the MU_ID to purRGED state, but retain the distrib- 
ution on the next-DSU queue for retransmission later. 


After checking that all MU_IDs in its registry are in NOT_ASSIGNED or PURGED 
state, the sender transmits a Reset-Request MU. The Reset-Request MU con- 
tains the MU_ID that the sender will transmit next--i.e., the value that the 
receiver should expect next--and a time stamp. The sender stores the time 
stamp as the “time of last reset” of its MU_ID registry. 
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Upon receiving the Reset-Request MU, the receiver checks to see whether any 
MU_IDs in its registry are in an active state (any state other than NOT_RECEIVED 
Or PURGED). If it finds any such MU IDs, the receiver refuses the Reset Request 
MU by returning CRMUs indicating the state of each active MU_ID. The sender 
responds to each CRMU with a PRMU, to allow the receiver to mark all MU_IDs 
PURGED. After responding to all the CRMUs, the sender sends another Reset- 
Request MU with a new time stamp. 


If, upon receipt of the Reset-Request MU, the receiver finds that all MU_IDs in 
its registry are in inactive states, it re-initializes its MU_ID registry such that its 
“next-expected” MU_ID is the MU_ID value sent in the Reset-Request MU. It 
stores the time stamp from the Reset-Request MU as the “time of last reset” of 
its MU_ID registry. The receiver then transmits a Reset-Accepted MU to the 
sender. In the Reset-Accepted MU, it echoes the MU_ID and time stamp from 
the Reset-Request MU. 


When the sender receives a Reset-Accepted MU in response to its last Reset- 
Request MU (indicated by the time stamp in the Reset-Accepted MU matching 
the time stamp stored by the sender) it re-initializes its MU_ID registry such 
that its “next-to-be-sent” MU_ID matches the value in the Reset-Accepted MU. 
If the sender receives a Reset-Accepted MU whose time stamp does not match 
the sender’s time stamp, it discards the MU. 


The “time-of-last-reset” time stamps may be used to detect out-of- 
synchronization conditions between the two MU_ID registries. For example, 
when DS _ Receive receives an MU_ID outside the range of MU_IDs that it is pre- 
pared to accept (i.e., the MU_ID is either too high or too low), it returns a REMU 
containing the MU_ID it received, the MU_ID it expected, and the time stamp of 
its MU_ID registry. DS_Send can then compare the time stamp with its own 
“time of last reset.” Ifthe time stamps do not match, DS_Send assumes that 
the registries are out of synchronization and initiates resynchronization. 


Exceptions Detected by the Distribution Transport Sublayer 


Exceptions Detected by DS_Send 
DS_Send informs DS_Receive that it has detected an exception by issuing a 
Send _ Error verb to LU 6.2 and sending a Sender-Exception Message Unit 
(SEMU). The processing performed by DS_Send and DS_Receive in response 
to a sender-detected exception is described below. 


The Sender-Exception Message Unit (SEMU) 
The SEMU is sent from DS_Send to DS_Receive. It is used to inform 
DS_Receive that DS_Send has detected an exception while processing a partic- 
ular DMU. SEMUs are always generated for sender-detected exceptions that 
involve high-integrity DMUs. A SEMU may be generated for a basic-integrity 
DMU, but is not required. A SEMU contains the MU_ID of the (high-integrity) 
DMU to which it pertains, along with a report code describing the exception 
condition. Appendix E lists the report codes used by DS. 
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Any exception that occurs after an MU_ID has been assigned to a particular dis- 
tribution is reported to DS_Receive via a SEMU, whether DS_Send has begun 
transmitting the DMU or not. 


DS_Send builds a SEMU at the time it detects an exception. DS_Send may also 
generate a SEMU if it detects that a previously issued SEMU has been lost. For 
example, suppose that DS_Receive inquires, via a CRMU, about an MU_ID that 
it has not received. If DS_Send has placed that MU_ID in TERMINATION_PENDING 
state, it assumes that the SEMU it previously sent was lost; DS_Send then 
rebuilds an identical SEMU and sends it to DS_Receive. See “Actions of 
DS_Send in Response to a CRMU” on page 95 for a description of DS_Send’s 
actions on receiving a CRMU. 


Effects of a Sender-Detected Exception on DS_Send 
When DS_Send detects an exception, it first determines whether the exception 
is recoverable or nonrecoverable. Exceptions that are inherently recoverable 
may be considered nonrecoverable after an implementation-defined number of 
transmission retries have been attempted. 


If the exception is inherently recoverable, DS_Send places an exception-hold on 
the next-DSU queue for the connection. This hold condition precludes all cur- 
rently active instances of DS_Send from retrieving distributions for trans- 
mission. The exception-hold condition may be lifted by operator intervention or 
by the attaching of a new instance of DS_Send by DS _Receive at the partner 
DSU. If the exception is inherently nonrecoverable, DS_Send does not place a 
hold on the next-DSU queue. 


If DS_Send is not currently processing a distribution (or if it has finished 
sending an entire distribution), it takes no furiher action. If DS_Send is proc- 
essing a high-integrity distribution, it places the MU_ID in either 
TERMINATION_PENDING OF RETRY_PENDING state depending on whether the excep- 
tion is nonrecoverable or recoverable, respectively. The state of the MU_ID 
indicates the intentions of DS_Send (i.e., either termination of the distribution or 
retransmission) pending knowledge of the state of the MU_ID at DS_Receive. 


If DS_Send is processing a basic-integrity distribution, it discards the distrib- 
ution if the exception is unrecoverable. If the exception is recoverable, 
DS_Send leaves the distribution on the queue to be retried later. 


If DS_Send has been reading an object from the server during transmission, it 
issues a verb to the server to terminate its access to the object. 


DS_ Send then informs DS_Receive of the exception. If it has begun transmitting 
the DMU to DS _ Receive, it informs DS_Receive by issuing Send_Error. If 
DS_Send has not begun transmitting the DMU, it does not issue Send _ Error. 

For a high-integrity DMU, DS_Send builds a SEMU (whether it has begun trans- 
mission of the DMU or not) describing the exception condition and enqueues it 
on the Control MU queue. For a basic-integrity DMU, DS_ Send may generate a 
SEMU but is not required to. 


Finally, DS_Send logs the exception condition. It leaves the distribution on the 
next-DSU queue for further processing. 
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Actions of DS_Receive in Response to Send_Error 
The Send_Error verb issued by DS_Send results in the receipt of either a 
Prog _Error_Trunc or a Prog Error_No Trunc indication by DS_ Receive. When 
DS_Receive receives the Prog Error indication on a high-integrity DMU, its 
actions depend on whether or not mid-MU restart is appropriate. 


If DS_ Receive decides that mid-MU restart is appropriate, it saves the partially 
received DMU on its mid-MU restart queue. It saves the partially received 
server object in the server space. It places the MU_ID in SUSPENDED state, 
pending receipt of the continuation of the DMU {i.e., pending receipt of a 
DCMU). 


If mid-MU restart is not appropriate, DS_Receive discards the partially received 
DMU and its server object. It places the MU_ID in TERMINATED state. If DS Send 
attempts retransmission, it will do so using a new MU_ID. 


When DS _ Receive receives a Prog Error on a basic-integrity DMU, it discards 
the partially received DMU. 


Actions of DS_Receive in Response to a SEMU 
When DS_Receive receives a SEMU, the actions it takes depend on the state of 
the MU_ID specified in the SEMU. If the MU_ID is NOT_RECEIvED, DS_Receive 
changes it to TERMINATED. If the MU_ID is SUSPENDED, DS_Receive examines the 
exception code in the SEMU. If the exception is inherently recoverable, the 
MU_ID is left in SUSPENDED state; if not, DS_Receive discards the partially 
received DMU (and any object associated with it) and changes the state of the 
MU_ID to TERMINATED. If the MU_ID is in any other state, the state is left 
unchanged. 


After performing the above actions, as appropriate, DS_Receive generates a 
CRMU to inform DS_Send of the state of the MU_ID (and the restart position, if 
the MU_ID is SUSPENDED). Finally, DS_Receive logs the information received in 
the SEMU. | 


If DS_ Receive receives a SEMU that does not contain an MU_ID (probably gen- 
erated while processing a basic-integrity DMU) it logs the receipt of the SEMU. 


Actions of DS_Send in Response to a Conversation Failure 
If DS_Send detects a conversation failure while transmitting a control MU, it 
leaves the control MU on the queue to be sent later. If the conversation failure 
occurs while DS_Send is transmitting a high-integrity DMU, DS_Send places the 
MU_ID in RETRY_PENDING state, terminates its access to the distribution and the 
server object, and generates a SEMU. The SEMU initiates recovery protocols 
with DS_ Receive. If DS_Send is transmitting a basic-integrity DMU, it simply 
leaves the DMU on the queue to be retried later. 
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Actions of DS_Send in Response to an Operator Purge 
An operator-initiated purge of an already-started distribution (i.e., a distribution 
that has already been assigned an MU_ID) is handled like a nonrecoverable 
exception. DS_ Send issues Send_Error followed by a SEMU, and places the 
MU_ID in TERMINATION_PENDING state. Following the receipt of a CRMU (TERMI- 
NATED), DS_Send will purge the distribution and issue a PRMU. 


Exceptions Detected by DS_Receive 
DS_Receive informs DS_Send that it has detected an exception by issuing a 
Send _ Error verb to LU 6.2 PS and sending a Receiver-Exception Message Unit 
(REMU). The processing performed by DS_Send and DS Receive in response 
to a receiver-detected exception is described below. 


The Receiver-Exception Message Unit (REMU) 
The REMU is sent from DS_Receive to DS_Send. It is used to inform DS_Send 
that DS_Receive has detected an exception condition while processing a partic- 
ular DMU. A REMU contains the MU_ID (for high-integrity traffic) of the DMU to 
which it pertains, an SNA_Condition_Report describing the exception condition, 
and certain other fields used by DS_Send to respond to the exception. 


The REMU is used to report both recoverable and nonrecoverable exceptions. 
DS _ Receive always generates REMUs for receiver-detected exceptions that 
involve high-integrity DMUs. DS_Receive may generate REMUs for exceptions 
involving basic-integrity traffic but is not required to do so. 


Effects of a Receiver-Detected Exception on DS_ Receive 
When DS_Receive detects an exception, it first informs DS_Send by issuing 
Send _ Error (assuming the conversation is still available-- if the conversation 
has failed, it cannot issue Send_Error). For high-integrity DMUs, the actions of 
DS_Receive following the Send_Error depend on whether the exception condi- 
tion is recoverable, and whether or not mid-MU restart is appropriate. 


If the exception is recoverable and DS_Receive decides that mid-MU restart is 
appropriate, DS_Receive issues a Terminate_Write verb to terminate its access 
to the partially received server object. It leaves the partially received DMU on 
the mid-MU restart queue. It places the MU_ID in SUSPENDED state, pending 
continuation of the transmission. 


If the exception is not recoverable or if DS_Receive decides not to attempt 
mid-MU restart, DS_Receive discards the partially received DMU and its server 
object. It places the MU_ID in TERMINATED state; if DS_Send attempts 
retransmission, it will do so using a different MU_ID. 


Finally, DS_Receive enqueues a REMU describing the exception condition on its 
control-MU queue, and logs the exception. 


For exceptions involving basic-integrity DMUs, DS_Receive simply discards the 
partially received DMU after issuing Send Error. 
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Actions of DS_Send in Response to Send_Error 
The Send _ Error verb issued by DS_Receive results in the receipt of a 
Prog Error_Purging indication by DS_Send. When DS_Send receives 
Prog Error Purging, it places the MU_ID in RETRY_PENDING state, pending the 
receipt of the REMU from DS Receive. If DS_Send has been reading a server 
object during transmission, it issues a server verb to terminate its access to the 
object; the server verb instructs the server to retain its mid-MU restart check- 
point information (if the server provides mid-MU restart capability). DS Send 
leaves the distribution on the next-DSU queue for further processing. If 
DS _ Send receives a Prog_Error_Purging indication while sending a basic- 
integrity DMU, it discards the DMU. 


Actions of DS_Send in Response to a REMU 
The actions taken by DS_Send in response to a REMU depend on the type of 
exception reported in the REMU. If the exception is not recoverable, DS_Send 
terminates the distribution (and any associated object), marks the MU_ID 
PURGED, sends a PRMU to DS Receive, and generates a distribution report, if 
appropriate, to inform the report-to DSU or user that the distribution was not 
delivered. 


If the exception is inherently recoverable, DS Send places an exception-hold on 
all next-DSU queues for the connection. The hold will be removed by operator 
action or by DS_Receive’s attaching another instance of DS_Send. 


If the exception is recoverable but the retry count has been exhausted for the 
DMU, DS_Send then treats the exception just as it would a non-recoverable 
exception. 


If the exception is recoverable and DS_Send decides to attempt mid-MU restart, 
DS _ Send issues a CQMU to determine the location in the DMU at which 
retransmission should begin. If the exception is recoverable but DS_Send 
decides not to attempt mid-MU restart, DS_Send marks the MU_ID PuURGED, 
sends a PRMU so that DS_Receive can mark the MU_ID PuRGED, and leaves the 
distribution on the next-DSU queue so that it can be retried later, with a dif- 
ferent MU_ID. 


However, if DS_Receive encounters a recoverable exception and DS_Send 
encounters a non-recoverable exception, DS_Send proceeds as it would for the 
non-recoverable exception. For example, suppose that DS_Send determines 
that the exception reported in the REMU is recoverable, but finds that the 
MU_ID has previously been placed in TERMINATION_PENDING state. After 
receiving the REMU, DS_Send would terminate the distribution. 


If the REMU indicates that the received MU_ID is a duplicate, DS_Send checks 
the MU_ID registry information returned in the REMU. If the MU_ID registries 
are synchronized, DS_Send discards the duplicate DMU. If the MU_ID registries 
are out of synchronization, DS_Send initiates a resynchronization sequence 
(see “Synchronization of MU_ID Registries at Sender and Receiver” on 

page 88). 


After completing the processing of the REMU as appropriate, DS_ Send logs the 
receipt of the REMU. 
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If both DS_Send and DS_Receive detect a conversation failure while processing 
a particular MU_ID, DS_Send may receive a REMU informing it of a conversa- 
tion failure of which it is already aware. In such a case, DS_Send discards the 
redundant REMU. 


If DS_Send receives a REMU that does not contain an MU_ID (probably gener- 
ated while processing a basic-integrity DMU) it logs the receipt of the REMU. 


Actions of DS_Receive in Response to a Conversation Failure 
If DS Receive detects a conversation failure while receiving a high-integrity 
DMU, its actions depend on whether mid-MU restart is appropriate. If it decides 
that mid-MU restart is appropriate, DS_Receive saves the partially received dis- 
tribution and server object and places the MU_ID in SUSPENDED state. Other- 
wise, it discards the distribution and server object and places the MU_ID in 
TERMINATED State. In either case, it generates a REMU and places it on the 
control-MU queue. The REMU notifies DS_ Send of the particular MU_ID that 
was interrupted by the conversation failure. 


If DS_Receive detects a conversation failure while receiving a basic-integrity 
DMU, it discards the partially received DMU. 


Other Control MUs (CQMU, CRMU, PRMU) 


DS_ Send and DS_ Receive use three other types of control MUs to exchange 
information about high-integrity DMUs. These MUs are not used to exchange 
information about basic-integrity MU_IDs (although DS_Receive may use the 
CRMU to send conversation control information (i.e., the terminate_conversation 
flag) while receiving basic-integrity traffic). 


Completion Query Message Unit (CQMU) 
The CQMU is sent from DS_Send to DS_Receive. DS_Send uses the CQMU to 
inquire about the state of a particular MU_ID at the adjacent DSU. A CQMU 
contains the MU_ID about which DS_Send is inquiring. A CQMU requests 
DS_Receive to return a CRMU describing the state of the MU_ID. 


CQMUs are not sent in normal exception-free situations. DS_Send issues an 
implicit request for a CRMU by sending a (high-integrity) DMU suffix or a SEMU; 
if the CRMU arrives in a timely manner, DS_Send has no need to send a 
CQMU. If the CRMU does not arrive in a timely manner, DS_Send issues a 
CQMU to solicit another CRMU. 


DS_ Send may also generate a CQMU in response to a REMU. If the exception 
reported in the REMU is recoverable, and if DS_Send wishes to attempt mid-MU 
restart, it issues a CQMU to determine the location at which it should begin its 
retransmission. 


A CQMU may also be generated if the sending DSU is restarted after a failure; 


the DSU may send a CQMU for any MU_ID if it is unsure of the state of that 
MU_ID at DS_Receive. 
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Actions of DS_Receive in Response to a CQMU 
If DS_Receive is able to find the entry in its MU_ID registry for the MU_ID speci- 
fied in the CQMU, it simply generates a CRMU to inform DS_Send of the state 
of that MU_ID. If the state of the MU_ID is SUSPENDED, the CRMU also contains 
an indication of the point at which retransmission should begin. 


lf DS_Receive is not able to find the entry in its MU_ID registry because the 
entry has been aged out, it returns a CRMU indicating that the MU_ID has been 
PURGED. If DS_Receive is not able to find the entry in its MU_ID registry 
because the entry has not yet been used, it returns a CRMU indicating that the 
MU_ID is NOT_RECEIVED. 


Completion Report Message Unit (CRMU) 
The Completion Report Message Unit (CRMU) is sent from DS_Receive to 
DS _ Send. It is used by DS_Receive to inform DS_Send of the state of a partic- 
ular MU_ID, and to control the traffic flow on the conversation. A CRMU may 
contain an MU_ID and flags indicating the state of that MU_ID at DS_ Receive. 
For an MU_ID in SUSPENDED state, the CRMU also contains the ID of the last 
high-level LLID structure received and the byte count of the last byte of that 
structure that was received. 


DS_Receive also uses the CRMU to instruct DS_Send to stop sending traffic on 
a conversation. See “Throughput Control” on page 79 for further details. 


DS_Receive generates a CRMU whenever it receives a request for one from 
DS_ Send. A request for a CRMU may be either explicit or implicit. DS Send 
explicitly requests a CRMU by sending a CQMU; DS _ Receive responds to the 
CQMU by generating a CRMU. DS_Send implicitly requests a CRMU by fin- 
ishing a particular transmission of a (high-integrity) DMU, that is, by sending 
either the suffix of a DMU or a SEMU. DS_Receive responds to a DMU suffix or 
a SEMU by generating a CRMU. 


DS_ Receive may also generate a CRMU if it detects that a transmission from 
DS _ Send has been lost. See “Lost Messages” on page 97 for further informa- 
tion on lost messages. 


Actions of DS_Send in Response to a CRMU 
A CRMU with MU_ID state COMPLETED acts as a confirmation to DS_Send that 
DS_Receive has accepted responsibility for the DMU. When DS_Send receives 
the CRMU (COMPLETED), it discards its copy of the distribution and marks the 
MU_ID PurGED. After doing so, it informs DS_ Receive by sending a Purge- 
Report MU (PRMU). The PRMU informs DS_Receive that it may mark the 
MU_ID PURGED, since DS_Send will not use that MU_ID in subsequent trans- 
missions. 


A CRMU with MU_ID state TERMINATED informs DS_Send that an exception was 
encountered during the processing of the DMU, and that mid-MU restart is not 
possible. If DS_ Send has previously placed the MU_ID in TERMINATION_PENDING 
state, it terminates the distribution, generates a distribution report if appro- 
priate, marks the MU_ID PURGED, and sends a PRMU to DS Receive. If the 
MU_ID is in any other state, DS_Send retries the transmission with a new 
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MU_ID. It marks the current MU_ID PURGED, sends a PRMU, and leaves the dis- 
tribution on the next-DSU queue to be retried later, using a different MU_ID. 


A CRMU with MU_ID state SUSPENDED informs DS_Send that an exception was 
encountered during the processing of the DMU, and that from DS_Receive’s 
point of view, mid-MU restart is possible. If DS_Send has placed the MU_ID in 
TERMINATION_PENDING State, it terminates the distribution, generates a distrib- 
ution report if appropriate, marks the MU_ID PURGED, and sends a PRMU to 
DS_Receive. If the MU_ID is in any other state and DS_Send wishes to attempt 
recovery using mid-MU restart protocols, it saves the restart position indicated 
in the CRMU and places the MU_ID in SUSPENDED state. DS_Send may then 
begin retransmission at a later time. If DS_ Send chooses to re-send the entire 
DMU rather than to attempt recovery using mid-MU restart protocols, it marks 
the MU_ID PURGED, sends a PRMU, and leaves the distribution on the next-DSU 
queue; it will be retried later using another MU_ID. | 


A CRMU with MU_ID state IN_TRANSIT informs DS_Send that the indicated DMU 
is still being received. DS Send ignores the CRMU unless it has placed the 
MU_ID in TERMINATION_PENDING Or RETRY_PENDING States; for an MU_ID in either of 
those states, DS_Send issues a CQMU to solicit another CRMU. 


A CRMU with MU_ID state NOT_RECEIVED informs DS_Send that DS_Receive has 
not received any part of the indicated DMU, nor has it received a SEMU indi- 
cating an error. DS Send ignores the CRMU if the MU_ID is in 
TRANSFER_PENDING State; it issues a SEMU if the MU_ID is in CQMU_PENDING or 
PURGED State. If the MU_ID is in TERMINATION_PENDING Or RETRY_PENDING state, 
DS_Send assumes the SEMU it sent earlier has been lost, and re-sends an 
identical SEMU. 


Purge-Report Message Unit (PRMU) 
The Purge-Report Message Unit (PRMU) is sent from DS_Send to DS_Receive. 
It informs DS_Receive that DS_Send has marked a particular MU_ID PURGED. 
The PRMU contains the MU_ID that has been purged. 


DS_Send never sends a PRMU unless DS_Receive has solicited it via a REMU 
or CRMU. DS_Send may mark an MU_ID PuRGED either because DS _ Receive 
has accepted responsibility for the DMU or because an exception has occurred 
and DS_Send has decided not to attempt recovery using the same MU_ID. 


Actions of DS_Receive in Response to a PRMU 
The PRMU informs DS_Receive that DS_Send has marked the specified MU_ID 
PURGED, and therefore that DS_Send has terminated the piece of work repres- 
ented by that MU_ID. Consequently, DS_Receive need no longer retain an 
explicit memory of the state of that piece of work. If the state of that MU_ID at 
DS_ Receive is anything other than SUSPENDED, DS_Receive simply marks the 
MU_ID PuRGED. DS_Receive may then “age out” the entry for the MU_ID from 
its MU_ID registry. If the state of the MU_ID is SUSPENDED, DS_Receive discards 
its partial copy of the DMU as well as marking the MU_ID PURGED. 


The PRMU does not imply anything in particular about the disposition of the dis- 


tribution itself, merely that the MU_ID has been marked PuRGED. The distrib- 
ution may have been successfully transferred, it may have been terminated and 
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Lost Messages 


a distribution report generated, or DS_ Send may have decided to retry it with a 
different MU_ID. 


The transfer of a high-integrity distribution from one DSU to another normally 
involves three messages. The sender sends the DMU itself; the receiver 
answers by sending a CRMU; the sender sends the PRMU. So long as none of 
these MuUs is lost, their exchange keeps MU_IDs staging through each DSU’s 
MU_ID registry. Each MU_ID moves from NOT_ASSIGNED (or NOT_RECEIVED) state 
to (eventually) PURGED state, and the oldest MU_IDs are “aged out” of the reg- 


istry. 


If one of the three MUs (DMU, CRMU, or PRMU) is lost, the result is an MU_ID 


that does not move to PURGED state in a timely manner. In particular, a DSU 
assumes that an MU has been lost if it finds an inappropriately “old” entry in its 
MU_ID registry for an MU_ID in an active state. If the state of the MU_ID indi- 
cates that a response regarding the MU_ID is expected from the partner, and if 
that response is not forthcoming, the DSU attempts to solicit the response. 


At DS_Send, the MU_ID states that indicate that a response is expected from 
the partner are TRANSFER_PENDING, CQMU_PENDING, TERMINATION _PENDING, and 
RETRY_PENDING. If the DSU finds that an MU_ID remains in one of these states 
for an inappropriately long period of time, it issues a CQMU for the MU_ID. The 
CQMU requests DS_Receive to return a CRMU indicating the state of the MU_ID 
at DS_Receive. Upon receipt of the CRMU, DS_Send is able to continue work 
on the MU_ID as appropriate. 


At DS_Receive, the MU_ID states that indicate that a response is expected from 
DS_Send are SUSPENDED, TERMINATED, and COMPLETED. In addition, the 
NOT_RECEIVED state may indicate that a DMU is expected from the partner, if 
DMUs with MU_IDs numbered above the NOT_RECEIVED MU_ID have already 
been received and marked PurGED. If an MU_ID remains in a “response- 
pending” state for too long, DS_Receive issues a CRMU indicating the state of 
the MU_ID. The CRMU requests DS_Send to send a DMU, SEMU, or PRMU, as 
appropriate. 


In general, the objective of each DSU is to reduce its number of “to-be-purged” 
MU_IDs, while at the same time exercising restraint so as not to flood the con- 
nection with CQMUs or CRMUs. The period of time that an MU_ID is allowed to 
remain in a “response-pending” state varies with the properties of the con- 
nection. 


On a single-session connection, for example, only two MU_ID entries might be 
needed in the receiver’s registry: one marked NOT_RECEIVED, the other marked 
PURGED. If an MU_ID greater than the current NOT_RECEIVED MU_ID were sent by 
DS_ Send, DS_Receive could reject it and issue a CRMU (NOT_RECEIVED) to solicit 
the MU_ID it expected. 


On a busy parallel-session connection, on the other hand, work might proceed 


on many MU_I[Ds concurrently. DS_Receive could find an entry in its MU_ID 
registry in NOT_RECEIVED state, even if several entries numbered above that 


Chapter 2. Overview of SNA/DS Protocols 97 


entry had already been received and marked PURGED. The NOT_RECEIVED MU_ID 
might simply have been delayed while making its way across one of the par- 
allel sessions. DS_ Receive would therefore wait longer before issuing the 
CRMU (NOT_RECEIVED) on the parallel-session connection than on the single- 
session connection. 


DS_Send solicits lost messages with CQMUs and DS Receive solicits lost mes- 
sages with CRMUs. DS_Send and DS _ Receive may issue as many CQMUs and 
CRMUs as necessary, until a response is received from the partner. Since 
DS_Receive replies to a CQMU by sending a CRMU, and since DS_Send typi- 
cally replies to a CRMU by sending a PRMU (even if the MU_ID has previously 
been purged, or even aged out of the registry), duplicate CQMUs or CRMUs 
cause no harm. Each DSU exercises appropriate restraint in sending CQMUs 
and CRMUs, however, to avoid flooding the connection with control messages. 


Mid-MU Restart 


If an exception occurs during the transmission of a DTIMU or DCMU, and if 
DS_Receive has successfully received the DMU at least through the | 
destination_list, DS_Receive may inform DS_ Send that mid-MU restart is pos- 
sible. The use of mid-MU restart allows the two DSUs to resume the failed 
transmission at or near the point of failure. 


The receiver uses the /ast_structure_received and the last_byte_received fields 
in the CRMU to inform the sender of the portion of the DMU that was success- 
fully received. If the receiver supports only LLID restart (i.e., it supports restart 
only at LLID boundaries, not within LLIDs), it informs the sender of the last high- 
level LLID structure that was completely received by specifying the ID of that 
structure in /ast_structure_received. It indicates that the structure was received 
in its entirety in one of two ways: either by specifying a value of 
X’FFFFFFFFFFFFFFFF’ for last_byte_received or by omitting the /ast_byte_received 
field entirely (the two methods are equivalent). 


If the receiver supports the byte-count restart elective, it may choose to inform 
the sender that restart within a structure is possible. It does so by specifying 
the ID of the last high-level LLID structure that was partially received in 
last_structure_received. It indicates the number of bytes of that structure that 
were successfully received (not including the LLID header bytes) in the 
last_byte_received field. 


Upon receipt of the CRMU containing mid-MU restart information, DS_Send 
builds a DCMU to continue the transmission of the distribution. If the CRMU 
indicates that the /ast_structure_received was received in its entirety (i.e., if 
last_byte_received is omitted or has a value of x’FFFFFFFFFFFFFFFF’), DS Send is 
expected to build a DCMU that begins with the structure immediately following 
the Jast_structure_received. However, DS_ Send may choose to restart with an 
earlier LLID structure. 


If the CRMU indicates a restart position within the /ast_structure_received (i.e., 
if last_byte_received is present and contains a value other than 
X’FFFFFFFFFFFFFFFF’), and if DS_Send is capable of byte-count restart, DS_Send 
builds a DCMU that begins with the portion of the /ast_structure_received imme- 
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Example 


diately following the /ast_byte_received. |If DS Send does not support the byte- 
count restart elective, it ignores the value in /Jast_byte_ received and restarts at 
the beginning of the /Jast_structure_received. 


DS_ Receive accepts a DCMU restarting the distribution at the position that was 
indicated in the CRMU. If the CRMU indicated that restart should begin at a 
particular LLID boundary, DS_Receive also accepts a DCMU restarting at a dif- 
ferent (earlier) LLID boundary. If the DCMU begins with an earlier LLID struc- 
ture, DS_Receive receives and discards the redundant transmission of the 
earlier structure(s). 


If the CRMU indicated that restart should begin at a particular byte location 
within the /ast_structure_received, DS_Receive accepts either a DCMU 
restarting at that location or a DCMU restarting at the beginning of the 
last_structure_received. |f the DCMU indicates a restart position within the 
last_structure_received different from that specified in the CRMU, DS_Receive 
may reject the DCMU. 


Figure 37 on page 100 illustrates the use of control MUs to accomplish mid-MU 
restart following a conversation failure. DS_Send allocates the conversation 
and begins sending, issuing verbs to the server to read the server object. 
Before DS_Receive receives the DTMU suffix, a conversation failure occurs. 


After allocating a new conversation (or on another already-active conversation), 
DS_Send issues a CQMU to query the state of the MU_ID at DS_Receive. 
DS_Receive issues Query_Last_Byte_Received to its server to determine the 
last byte of the server object that was received. DS Receive then transmits a 
CRMU specifying /ast_structure_received as SERVER_OBJECT and 
last_byte_received as the byte number supplied by the server. If DS_Receive 
has not received any part of the server object or if the receiving DSU does not 
support the byte-count restart elective, DS_ Receive returns the ID of the last 
high-level LLID structure it has fully received (either the agent object or an 
unrecognized field) in /ast_structure_received, and indicates that the structure 
was fully received either by specifying a value of x’FFFFFFFFFFFFFFFF’ for 
last_byte_received or by omitting the /ast_byte_received field entirely. 


Upon receipt of the CRMU, DS_Send issues server verbs specifying restart 
information to begin reading the server object at the byte following the byte 
specified by /ast_byte_received. DS_Send encodes a DCMU containing the 
remainder of the server object and sends it to DS_Receive. DS_ Receive issues 
server verbs specifying restart information to store the remainder of the server 
object, and, upon receipt of the DTMU suffix, accepts responsibility for the dis- 
tribution. DS Receive then transmits a CRMU (COMPLETED) and receives a 
PRMU. 


If the CRMU (SUSPENDED) specifies a last_byte_received value other than 
X’FFFFFFFFFFFFFFFF’ but DS_Send does not support the byte-count restart elec- 
tive, DS_Send ignores the /ast_byte_received value and restarts at the begin- 
ning of the server object. 
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Figure 37. Example--Mid-MU Restart 
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Formal Description of MU_ID State Transitions 


DS _SEND_MU_STATE_DESCRIPTION 


This finite-state machine describes the MU_ID state transitions that occur at DS_Send. Actions 
accompanying the state changes (such as generating a Distribution Report for a distribution 
entering Purged state) are not given here. See the FSMs describing DS_Send for further detail. 


The CRMU input signals indicate that a CRMU was received with the indicated MU_ID state. If 
the MU_ID state in the CRMU is SUSPENDED, processing differs depending on whether or not 
Mid-MU Restart is appropriate. The SEMU input signals indicate that DS_Send encountered an 
exception (retriable or not, as indicated) and generated a SEMU. The REMU input signals indi- 
cate that a REMU was received indicating an exception (retriable or not, as indicated). 
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DS _RCV_MU_STATE_DESCRIPTION 


This finite-state machine describes the MU_ID state transitions that occur at DS_Receive. 
Actions accompanying the state changes are not given here. See the FSMs describing 
DS_Receive for further detail. 


The After Failure Restart, Conv Fail, and Prog Err Recvd input signals indicate the exception 
condition that was detected and whether or not Mid-MU Restart was appropriate. The SEMU 
input signals indicate that a SEMU was received indicating an exception (retriable or not, as 
indicated). The REMU input signals indicate that an exception was detected (retriable or not, as 
indicated) and a REMU generated. 
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Chapter 3. Implementation Model 


Introduction 


This chapter presents an implementation model of a distribution service unit. 
The introductory section presents an overview of the transaction programs and 
data structures that comprise the DSU. The functions of the DSU are organized 
by DS sublayers. Diagrams illustrate the components of the DSU and the 
relationship of the DSU to the other parts of the network--the agents that use 
DS and the LU at which the DSU resides. The LU makes the services of the 
underlying communication network available to the DSU. 


Following the introduction are groups of finite-state machines (FSMs) that illus- 
trate the structure of the DSU in greater detail. The finite-state machines are 
grouped by DS sublayer. When the FSMs are executed, they generate 
sequences conforming to DS protocols. 


The Structure of a DSU 


Figure 38 on page 108 illustrates the components of the DSU and their relation- 
ship to the DS sublayers. (For simplification, the later diagrams do not show 
the DS sublayers.) The functions of the DS presentation services sublayer are 
provided by a DS presentation services program. The functions provided by the 
directing and routing sublayers are provided by the service transaction program 
DS_Router_Director. The functions of the distribution transport sublayer are 
provided by two service transaction programs, DS_Send and DS Receive. An 
explanation of the numbered components of the DSU follows the figure. 


The local-delivery queues are associated with both the presentation services 
and directing sublayers. The router-director queue is associated with both the 
directing and routing sublayers. The next-DSU queues are associated with both 
the routing and distribution transport sublayers. 


The DS operations functions are associated with all DS sublayers. The pro- 


grams that perform the operations functions for exception processing are 
invoked from the programs that detect the exception conditions. 
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Figure 38. Structure of a DSU 


The numbered components are: 


1. The users: Users interact with transaction programs known as agents to 
send and receive distributions and to invoke operations functions. 


2. The agents: The agents are above the DS protocol boundary. They interact 
with DS by issuing protocol boundary verbs. For outbound traffic, an agent 
issues a sequence of verbs known as a sending sequence. For distributions 
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10. 


11. 


12. 


13. 


14. 


to be delivered locally, DS selects the appropriate local-delivery queue 
according to contents of the directory and schedules the specified destina- 
tion agent. The agent then issues a sequence of verbs known as a 
receiving sequence to receive the distribution. Further detail on the agent 
protocol boundary, sending sequences, and receiving sequences may be 
found in Chapter 1 and Appendix F. 


. The agent protocol boundary: It provides the interface between the agents 


and DS. 


. The server protocol boundary: \t provides the interface between DS and the 


servers. For outbound distributions, DS gets read access to the server 
object by issuing verbs to the server across this boundary. For inbound dis- 
tributions, DS issues verbs to store the server object. 


. DS presentation services: Presentation services validates the requests from 


the agents, schedules further distribution functions, and provides return 
codes and parameters to the agents. 


. The router-director queue: This queue contains distributions originated 


locally (placed on the queue by presentation services) or received from 
remote DSUs (placed on the queue by DS_Receive). When DS& is required 
to generate distribution reports, DS operations places them on the queue. 
The queue is serviced by DS_Router_Director. 


. The local-delivery queues: These queues contain distributions awaiting 


delivery by DS presentation services to local agents. The directing function 
of DS_Router_Director places distributions on the queues; it selects the 
appropriate queue based on parameters in the directory and information in 
the distribution. Presentation services services the queue when an agent 
issues Receive_ Distribution. 


. DS_Router_Director: This service transaction program performs the func- 


tions associated with both the routing and directing sublayers. It services 
the router-director queue, accesses the directory and the routing tables, 
and places distributions on the local-delivery queues or next-DSU queues. 


. The directory: \t contains information that enables DS_Router_Director to 


associate a destination DSU name with a destination user and local delivery 
information with a local user. 


The routing table: \t contains information that enables DS_Router_Director 
to select the appropriate next-DSU queue for outbound distributions. 


The next-DSU queues: These contain distributions to be transmitted to 
remote DSUs. DS_Router_Director places entries on the queues. DS Send 
services the queues. 


DS_Send: This service transaction program performs the functions required 
to send distributions to adjacent DSUs. 


DS Receive: This service transaction program performs the functions 
required to receive distributions from adjacent DSUs. It uses server verbs 
to store server objects and places distributions on the router-director 
queue. 


The LU 6.2 basic conversation protoco/ boundary: This interface enables DS 
to issue LU 6.2 verbs to send and receive distributions. 
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15. DS operations: These programs perform functions required when 


16. 


exceptions are detected or when operations users display or change DSU 
information. These programs can be invoked from any of the other DS 
transaction programs. 


The exception log: This log contains information concerning exception inci- 
dents detected by DS. DS creates the entries. DS operations programs 
access the entries for operators. 


Examples of DSU Activity s 
The diagrams in this section show the interaction of the components described 
in “The Structure of a DSU” on page 107 for various distribution activities. 


Origin of Distribution with Local Destinations 
Figure 39 on page 111 shows the interaction of the DSU components when a 
user sends a distribution to another user or users, all local to the same DSU. 


Refer to Figure 39 on page 111 for the following interactions. 


1. 
2. 


12. 


The user interacts with an agent to initiate a distribution request. 


The agent issues Send_Distribution to DS. Presentation services programs 
analyze the request information and accept it. | 


. Presentation services signals SERVER_MGR to increment the DS lock count 


for the server object. SERVER_MGR issues Assign _Read_ Access to the 


server. 


. The distribution is placed on the router-director queue and | 


DS_Router_Director is scheduled. 


. An OK return code is returned to the agent. The agent issues 
Sending Sequence Completed. 


. DS_Router_Director accesses the distribution on the router-director queue. 


It recognizes that the distribution is at its origin and invokes directing. 


. Directing reads the directory and determines that all destination users are 


local. 


. Information in the directory is used to select the appropriate local-delivery 


queues for the distribution. The destination agent is scheduled. The iden- 
tification of the queue is supplied to the agent. 


. The agent issues Receive_Distribution. 
10. 


Presentation services accesses the named local-delivery queue and reads 
the distribution information. 


. The distribution information is returned to the sgenk The egem issues 


Receiving_Sequence_Completed. 


The agent provides the distribution information to the user. 


110  SNA/Distribution Services Reference 


Users 


Agent PB 
DS 
Presentation 
Services 
Server 

PB (10) 


Server local- DS 
| | delivery Oper- 
queues ations 


(8) Directory 


(7) 
Exception 
Log 
DS_ROUTER_ 
Tf DIRECTOR 
Routing 
router- Table 


director 
- = 
next-DSU 


| | queues 


_ mal 


LU 6.2 
Basic Conversation 
PB 


Figure 39. Processing at the Origin of a Distribution with Local Destinations 
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Origin of Distribution with Remote Destinations 
Figure 40 shows the component interaction at the origin of a distribution that 
has remote destinations. 
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Figure 40. Processing at the Origin of a Distribution with Remote Destinations 
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10. 


12. 
13. 


14. 


. The user interacts with an agent causing it to initiate a distribution request. 


. The agent issues Send_Distribution to DS. The request information is 


accepted by presentation services programs. 


. Presentation services signals the server manager to increment the DS lock 


count for the server object. The server manager issues 
Assign _Read_ Access to the server. 


. The distribution is placed on the router-director queue, and 


DS_Router_Director is scheduled. 


. An OK return code is returned to the agent. 


. DS_Router_Director accesses the distribution on the router-director queue. 


It recognizes that the distribution is at its origin. 


. The directory contents are read to determine the destination DSU for each 


destination user. The distribution is passed to routing. 


. The routing table is accessed to determine the next-DSU queue for the dis- 


tribution. 


. The information is placed on the selected next-DSU queue, and DS_Send is 


scheduled. 


DS_Send accesses the next-DSU queue. 


. DS_Send starts a conversation via LU 6.2 with DS_Receive at the adjacent 


DSU. That DSU may or may not be the destination; the sending process is 
the same. 


A server verb is issued to read the server object. 


The server object is retrieved from the server and encoded as part of the 
DTMU. Multiple Read verbs may be required to read the entire server 
object. 


The DTMU is transmitted to the adjacent DSU. 
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Destination of Distribution 
Figure 41 illustrates the processing when a DSU receives a distribution whose 
destinations are local. 
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Figure 41. Processing a Received Distribution at the Destination 


1. DS_Receive is attached by LU 6.2 as a result of Bey initiated by 
DS_Send in the sending DSU (not shown). 
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11. 
12. 


. The DTMU is received. Multiple LU 6.2 verbs may be issued to receive the 


entire DTMU. 


. DS_ Receive issues server verbs to allocate space for the server object. 
. The server object is stored by the server. 


. The distribution is placed on the router-director queue and 


DS_Router_Director is scheduled. 


. DS_Router_Director accesses the distribution. Routing determines that the 


local DSU is a destination for the distribution and invokes directing. 


. Directing accesses the directory, determines that the distribution is to be 


delivered locally, and gets the local delivery information (local-delivery 
queue identifier and parameters). 


. Directing places the distribution on the appropriate local-delivery queue and 


schedules the destination agent. The queue identifier is passed to the 
agent. 


. The agent issues Receive_Distribution. 


. A presentation services program accesses the indicated local-delivery 


queue and reads the distribution. 
The distribution information is returned to the agent. 


The agent returns information to the user. 
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Processing a Received Distribution with a Routing Exception 
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Figure 42. Processing a Received Distribution with a Routing Exception 
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Figure 42 on page 116 illustrates the processing performed by the DSU when a 
routing exception occurs during the processing of a distribution. For this illus- 
tration, assume that the routing table accessed by DS_Router_Director has an 
error so that the destination DSU is not listed in it. This could result from to an 
error in building the table or because the table has been improperly changed. 


1. 


11. 
12. 
13. 


DS_Receive is attached by LU 6.2 as a result of activity (not shown) initiated 
by DS_Send in the sending DSU. 


. The DTMU is received. Multiple LU 6.2 verbs may be issued to receive the 


entire DTMU. 


. DS Receive issues server verbs to allocate space for the server object. 
. The server object is stored by the server. 


. The distribution is placed on the router-director queue and 


DS_Router_Director is scheduled. 


. DS_Router_Director accesses the distribution. The destination DSU name 


in the distribution is not local. 


. DS_Router_Director accesses the routing table to select the next-DSU 


queue for the distribution. The destination DSU and service level required 
are not found in the routing table. 


. DS_Router_Director invokes DS Operations to process the exception condi- 


tion. 


. DS Operations records exception information in the exception log. 


10. 


DS Operations creates a distribution report, places it on the router-director 
queue, and schedules DS_Router_Director. From this point, the distribution 
report is processed the same as any other distribution on the router- 
director queue. 


DS Operations releases the server object by issuing server verbs. 
DS Operations issues a message to the operator indicating the exception. 


An agent displays exception information to an operator. 
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Accessing Logged Exception 


118 


Figure 43 illustrates the processing when an operator accesses the exception 
information on the exception log. 
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Figure 43. Accessing a Logged Exception 
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1. An operator interacts with an agent to access the contents of the exception 
log for a particular distribution. 


2. The agent issues the Get_Exception_Log Entry verb, identifying the distrib- 
ution. A presentation services program accepts the verb. 


3. The presentation services program invokes DS Operations to access the 
exception log with the identification of the required distribution. 


4. DS Operations accesses the exception log and locates the distribution infor- 
mation. 


5. DS Operations returns the information to the presentation services 
program. 


6. The presentation services program returns the exception information to the 
requesting agent. 


7. The agent formats the information for the operator. 


Presentation Services Sublayer 


This section presents a description of the functions performed by the presenta- 
tion services sublayer in response to the various verbs that an agent may 
issue. 


Send_ Distribution 
Presentation services performs the following actions in response to a 
Send _ Distribution verb: 


e The syntax of the verb and dependencies among the parameters are 
checked. 


e The parameters of the verb are validated. For information on the required 
protocol boundary checking performed by all implementations, see 
Appendix C. 


¢ The DS lock count for the server object is incremented. 
Assign_Read_Access is issued to the server, to ensure that DS has read 
access to the server object and that the server object will not be prema- 
turely deleted. 


¢ The distribution is placed on the router-director queue. 
e DS Router_Director is scheduled. 


e The sending state for the distribution is updated. For a description of the 
possible values of the sending state, see Appendix F. 


e« Control is returned to the agent. 
Query_Distribution_Sending 


Presentation services performs the following actions in response to a 
Query_Distribution Sending verb: 


¢ The syntax of the verb and dependencies among the parameters are 
checked. 


e The parameters of the verb are validated. 
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¢ The control block for the distribution is located and the distribution control 
information is obtained. 


¢ Control is returned to the agent along with the appropriate distribution infor- 
mation. 


Sending_Sequence_Completed 
PS performs the following actions in response to a 
Sending Sequence_Completed verb: 


¢ The syntax of the verb and dependencies among the parameters are 
checked. 


e The parameters of the verb are validated. 


e The sending state is checked to see that the Sending Sequence_Completed 
verb is appropriate. 


e The distribution control block is located. 
¢ The sending state for the distribution is updated as appropriate. 
e Control is returned to the agent. 

Receive_Distribution, Receive_Distribution_Report 


PS performs the following actions in response to a Receive_Distribution or a 
Receive_Distribution_Report verb: 


e The syntax of the verb and dependencies among the parameters are 
_ checked. 


¢ The parameters of the verb are validated. 
¢ The distribution is retrieved from the local delivery queue. 


e The distribution control block is marked as received and a time stamp is 
saved. 


¢ The distribution information is returned to the agent. 
Recelving_Sequence_Completed 


PS performs the following actions in response to a 
Receiving Sequence_Completed verb: 


e The syntax of the verb and dependencies among the parameters are 
checked. 


e The parameters of the verb are validated. 


e The distribution control block is located and checked to see that the distrib- 
ution has previously been received. 


e The agent lock count is decremented for the server object. If both the DS 
and agent lock counts are 0 following the decrement operation, 
Release_Read_Access is issued to the server to release access for both DS 
and the agent. 


¢ The distribution copy is dequeued from the local delivery queue. 
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e If Receiving Sequence _Completed has been issued for all copies of the dis- 
tribution, the distribution control block is deleted. 


e Control is returned to the agent. 


Obtain_Local_Server_Report 
PS performs the following actions in response to an 
Obtain _Local_Server_Report verb: 


e The syntax of the verb and dependencies among the parameters are 
checked. 


e The parameters of the verb are validated. 
e The server report is obtained from the appropriate local delivery queue. 


e The server report is returned to the agent. 


Operations Verbs 
For a description of the operations verbs, see Chapter 1 and Appendix F. PS 
performs the following actions in response to an operations verb: 


e The syntax of the verb and dependencies among the parameters are 
checked. 


e The parameters of the verb are validated. 
e The requested operation is performed. 


¢ The results of the verb are returned to the agent. 


Routing and Directing Sublayers 


Routing and Directing Overview 
The formal model groups these functions together under a single transaction 
program, but DS implementations may choose other groupings. This model 
also shows some option subsets, which implementations may or may not 
decide to support. However, all DS implementations provide the base DS func- 
tions, as described in Appendix C. 


The machines in this section correspond to the transaction program 
DS_Router_Director. A manager machine controls lower-level machines in the 
hierarchy. The manager machine loops, removing distributions from the router- 
director queue, and signals lower-level machines to perform either the routing 
function or the directing function. 


DS_ Router Director has the responsibility of enqueuing a distribution either 
locally for delivery, or on a next-DSU queue from which it will be transmitted to 
an adjacent DSU. 


There are two components: 


¢ Routing processes distributions originating locally or remotely, examines 
the DSU names, and either gives them to directing for local handling, or 
queues them again for transmission onward. 
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e Directing performs directory lookup and local delivery functions. For distrib- 
utions that were originated locally, it supplies DSU names for user destina- 
tions that are to be transmitted for delivery elsewhere. Directing also 
delivers distributions locally; that is, it puts them on local queues and 
causes designated local agents to gain control. Another function of 
directing is that of redirection. In performing this function, the distribution is 
passed from routing to directing and back to routing with new destination 
DSUs for some user destinations. This communication takes place through 
the manager machine. 
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FSM_SCHED_MGR 
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FSM ROUTING DIRECTING MGR 


FSM_ QUEUE_MGR FSM_DEST_ SERVER_ FSM_ FSM_ 
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MGR x * x MGR MGR 
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MGR MGR SCHED. | | NEXT_ MGR MGR SCHED_ 
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* indicates those finite-state machines not formally specified. 


For more details regarding the finite-state machines, see: 


"FSM ROUTING DIRECTING MGR" on page 124 
"FSM_LOCAL_SCHED" on page 132 
"FSM_DIRECTING_MGR" on page 128 
"FSM_REMOTE_SCHED" on page 140 
"FSM_ROUTING MGR" on page 136 
"FSM_SCHED_MGR" on page 351 
"FSM_OPERATIONS. MGR" on page 342 
"FSM_ORIGIN CHECK" on page 144 
"FSM_NEXT_LOCAL_ QUEUE" on page 145 


"QUEUE_MGR" on page 357 

"FSM _COUNT_EXCEPTS" on page 145 
"FSM _DEST_DSU_CHECK" on page 144 
"FSM_DSU_CHECK" on page 145 
"SERVER_MGR" on page 354 
"FSM_RTG_LOOKUP" on page 145 
"FSM_DIR_LOOKUP" on page 144 
"FSM_NEXT_DSU" on page 146 
"FSM_LOCAL_CHECK" on page 144 
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Figure 44. DS_Router_Director FSM Hierarchy 
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FSM_ROUTING DIRECTING MGR 
This machine controls the sequence of routing and directing functions for each 
distribution. It uses information in the distribution, and signals lower-level 
machines to accomplish its functions. In the case of exceptions reported by 
lower-level machines, this machine takes exception information passed from 
those machines and gives it to FSM OPERATIONS MGR for processing. 


FSM_ROUTING_ DIRECTING MGR is started by a signal from FSM_SCHED_MGR. 
It processes entries on the router-director queue until the queue is empty. 

First, it signals QUEUE MGR to remove a distribution from the router-director 
queue. When the distribution is dequeued, FSM_ROUTING DIRECTING MGR 
determines whether it originated locally and has at least one user destination. 
If it originated locally and at least one user destination is present, the distrib- 
ution is passed to the directing manager, which performs local distribution and 
fills in DSUs for remote user destinations. 


When FSM_ROUTING_DIRECTING MGR receives the DIRECTING COMPLETE 

signal, it passes the distribution to the routing manager, if distribution copies 

for remote destinations are to be processed. If, however, all the destinations 

happen to be local, it decrements the server-object DS lock count, which was 
incremented when the distribution entered the DSU, and asks for the next dis- 
tribution on the router-director queue. 


If the distribution originated at a remote DSU, FSM_ROUTING_DIRECTING MGR 
passes the distribution to the routing manager first. If any of the destination 
DSUs are local, the routing manager requests that the directing function be per- 
formed on the distribution. If no DSUs are local, the routing manager puts the 
distributions on the appropriate next-DSU queues. 


When FSM_ROUTING_DIRECTING_ MGR receives the DIRECTING COMPLETE 
signal, the distribution has been enqueued for delivery to any local users or 
agents, and these local destinations have been removed from the distribution. 
There may or may not be destinations remaining. When 

FSM_ROUTING DIRECTING MGR receives the ROUTING COMPLETE signal, no 
more destinations are to be serviced for the distribution and 

DS_Router_ Director processing is complete. Any fan-out is performed by the 
routing manager and the directing manager. 


Only two exceptions are reported to FSM_ ROUTING DIRECTING MGR: a 
server exception and a queue exception. In both these cases, it signals 
FSM_OPERATIONS_MGR to log the exception and send a message to the oper- 
ator so that the affected resources can be repaired. 


Exceptions in directing and routing are handled by FSM_DIRECTING MGR and 
FSM_ROUTING MGR. The DIRECTING COMPLETE and the 

ROUTING COMPLETE signals imply that any exceptions have been processed 
and that erroneous user names and DSUs, or destinations for which delivery 
could not be made, have been erased from the distribution. 
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Function: This finite-state machine describes the sequence of routing and directing functions in 
DS_Router_Director. For a further description, see “FSM _ROUTING_DIRECTING MGR” on 
page 124. 


This FSM gets control from one of the following: 
¢ Signals from finite-state machines providing common services: 


START_TRANSACTION from FSM_SCHED MGR 
QUEUE_OK from QUEUE_MGR 

QUEUE _NOT_OK from QUEUE_MGR 

QUEUE_EMPTY from QUEUE_MGR 

OPERATIONS. COMPLETE from FSM_OPERATIONS._ MGR 
OBJECT_OK from SERVER_MGR 

OBJECT _NOT_OK from SERVER_MGR 


Signals from lower-level routing and directing finite-state machines: 


ORIGIN. REQUEST_USER_NAME from FSM_ORIGIN_ CHECK 
ORIGIN. REQUEST _NO_USER_NAME from FSM_ORIGIN_ CHECK 
NOT_ORIGIN REQUEST from FSM_ORIGIN_ CHECK 

DIRECTING COMPLETE from FSM_DIRECTING_MGR 

ROUTING COMPLETE from FSM_ROUTING MGR 

ROUTING RESET from FSM_ROUTING MGR 

DIRECTING REQUIRED from FSM_ROUTING_MGR 
DEST_DSUS_REMAINING from FSM_DEST_DSU_CHECK 
NO_DEST_DSUS_REMAINING from FSM_DEST_DSU_CHECK 
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Output 
Code 


Signal QUEUE_MGR with READ@Q to read the next available entry from the router-director queue. 


Signal FSM_ORIGIN_CHECK with CHECK_FOR_ORIGIN to determine if the distribution is at the 


origin. 


Signal FSM_DIRECTING_ MGR with DIRECT to determine the DSU for each destination. 


Signal FSM_ROUTING_ MGR with ROUTE to determine local and remote destinations, perform 
fan-out, and perform scheduling for remote destinations, if all destinations are remote. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count for the server 
object. If no server object exists, SERVER_MGR returns OBJECT_OK. 


Signal FSM_OPERATIONS_MGR with LOG_MESSAGE_EXCEPT to perform logging and to display an 
operator message. Any asynchronous reporting required was generated from either directing or 
routing. 


Signal FSM_DEST_DSU_CHECK with CHECK_DSUS to determine if any destination DSUs remain to 
be handled by routing. 


Signal QUEUE_MGR with DEQ to remove the entry processed from the Router-Director queue. 


Signal FSM_ROUTING MGR with ALL_LOCAL to indicate no more DSUs remain to be processed. 
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Directing FSMs 
FSM_DIRECTING MGR 


The directing manager accesses the user directory and handles the local- 
delivery and redirection functions. The directing manager: 


e Looks up user names and agents in the directory and obtains DSUs and 
local-delivery queue information where necessary. 


¢ Signals the DS operations manager to handle any exceptions found in the 
destination list. 


e Checks whether any local recipients are in the destination list. 


¢ Puts the distribution on local-delivery queues for local recipients and 
removes them from the destination list. 


e Passes any redirected destinations back to the 
FSM_ROUTING_DIRECTING MGR. 


The directing manager receives one of two types of input from the 
FSM_ROUTING_DIRECTING_ MGR: 


¢ A distribution that originated locally. 


¢ A distribution that originated at a remote DSU, and that the routing 
manager has determined to have at least one destination local to this DSU. 
This type of distribution is assumed to have the apparent local destination 
DSUs and user names marked for the directing manager. 


For destination users and agents, the directing manager first signals 
FSM_DIR_LOOKUP to access the user directory. Next, the directing manager 
signals FSM _LOCAL_CHECK to check the queue information appended by 
FSM_DIR_LOOKUP to determine if the distribution can be delivered locally. 
FSM_LOCAL_CHECK will fan out the distribution if necessary. 


If no queue information was appended, then no local deliveries are to be made, 
and directing signals the FSM_ROUTING_DIRECTING_MGR that the directing 
function is complete. If local deliveries are to be made, the directing manager 
machine signals FSM_LOCAL_ SCHED to queue the distribution to each of the 
local recipients in the destination list. When FSM_LOCAL_SCHED is done, the 
directing manager signals back to the FSM_ROUTING DIRECTING MGR that 
directing is done. 


If exceptions are found in the directing operation, the directing manager 
machine signals the operations manager to handle the exceptions. Operations 
is given a list of the exception destinations, logs the exception, builds the dis- 
tribution exception report, and notifies the operator if necessary. 


Upon signalling back to FSM ROUTING DIRECTING MGR, the directing 
manager has pruned all local recipients from the destination list, so that either 
no recipient remains, or only recipients at remote DSUs remain. Either all local 
recipients have had the distribution enqueued, or, if there were exceptions, the 
proper exception recovery action was taken. 
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Function: This finite-state machine describes the functional processing in directing. For a further 
description, see “FSM_DIRECTING_MGR” on page 128. 


This FSM gets control from one of the following: 
¢ Signals from higher-level routing and directing finite-state machines: 
— DIRECT from FSM_ROUTING_ DIRECTING MGR 
Signals from lower-level routing and directing finite-state machines: 


DIR_LOOKUP_COMPLETE_NO_EXPTS from FSM_DIR_LOOKUP 
DIR_LOOKUP_COMPLETE_EXPTS from FSM_DIR_LOOKUP 
DIRECTING_LOCALS from FSM_LOCAL_CHECK 

DIRECTING NO_LOCALS from FSM_LOCAL_CHECK 
DIRECTING_LOCALS_COPY_EXPT from FSM_LOCAL_CHECK 
LOCAL_SCHED_COMPLETE from FSM_LOCAL_SCHED 
LOCAL_SCHED_COMPLETE_EXPTS from FSM_LOCAL_ SCHED 


Signals from finite-state machines providing common services: 
— OPERATIONS_COMPLETE from FSM_OPERATIONS MGR 


ee a ec 


foreRarions commute [7 [7 | [|] | a 


130 SNA/Distribution Services Reference 


Signal FSM_LOCAL_CHECK with CHECK_LOCALS to determine if local queue information exists for 
any destinations. If local destinations exist, FSM _LOCAL_CHECK makes a copy of the server object, 
using the appropriate server. 


Signal FSM_ROUTING_DIRECTING_MGR with DIRECTING COMPLETE to indicate that all destination 
users have been completed with DSUs, any local distribution has been performed, and any 
exceptions have been processed by FSM_OPERATIONS_MGR. 


Signal FSM_LOCAL SCHED with LOCAL_DISTRIBUTIONS to schedule the destination agent for proc- 
essing of local distributions. 
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FSM_LOCAL_SCHED 
This machine shows the sequence of functions comprising the local delivery 
mechanism in DS. FSM_LOCAL_SCHED uses the local-delivery queue informa- 
tion and the copies of the distribution that FSM _LOCAL_ CHECK made. 


The directing manager machine signals FSM_LOCAL_ SCHED when it deter- 
mines that it has local destinations for the distribution. For each local-delivery 
queue identifier, FSM_LOCAL_ SCHED does the following: 


e Requests the next queue identifier and a copy of the distribution from 
FSM_NEXT_LOCAL QUEUE. 


e Increments the server object agent lock count. 


¢ Enqueues the copy of the distribution on the local-delivery queue specified 
by the queue identifier. 


e Schedules the destination agent identified in the distribution. 


e Makes the queue entry available to the agent by a RELEASEQ signal to 
QUEUE_MGR. 


If an exception occurs during the processing, FSM_LOCAL_ SCHED does the fol- 
lowing: 


e Reverses any operation that has been done on the distribution up to that 
point. 


For example, if the server object agent lock count has been incremented 
and the distribution put on the local-delivery queue, FSM LOCAL SCHED 
dequeues the distribution and decrements the server-object agent lock 
count. 


e Adds the destinations in the destination list of the reported-on distribution to 
a general exception list to be passed back to the directing manager 
machine. 


When all the local-delivery queue identifiers are exhausted, 
FSM_LOCAL_SCHED checks for any exceptions that have occurred in the 
process, and returns the list of destinations for which the distribution could not 
be enqueued. If no exceptions were found, FSM LOCAL SCHED reports 
LOCAL SCHED_COMPLETE back to the directing manager machine. 


Although it is not shown in this machine, for an unsuccessful server, queue, or 
scheduling function, FSM_OPERATIONS_MGR should also be signalled with 
MESSAGE_TO_OPERATOR and passed the message that the operation could 
not be completed, and that, in handling the exception, another exception 
occurred. | | 
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Function: This finite-state machine describes the functional processing for local delivery in directing. For 
a further description, see “FSM LOCAL SCHED” on page 132. 


This FSM gets control from one of the following: 


¢ Signals from higher-level routing and directing finite-state machines: 
— LOCAL_DISTRIBUTIONS from FSM_DIRECTING_MGR 


Signals from lower-level routing and directing finite-state machines: 


— NEXT_QUEUE_ID from FSM_NEXT_LOCAL_QUEUE 
— END QUEUE_IDS from FSM_NEXT_LOCAL_QUEUE 
— SCHED _NO_EXCEPTS from FSM_COUNT_EXCEPTS 
— SCHED EXCEPTS from FSM_COUNT_EXCEPTS 


Signals from finite-state machines providing common services: 


OBJECT_OK from SERVER_MGR 

OBJECT _NOT_OK from SERVER_MGR 

QUEUE_OK from QUEUE_MGR 

QUEUE _NOT_OK from QUEUE_MGR 

SCHED FUNCTION OK from FSM_SCHED_MGR 

SCHED FUNCTION NOT_OK from FSM_SCHED_MGR 


States 
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Signal FSM_NEXT_LOCAL QUEUE with FIND NEXT QUEUE_ID to determine the next local-delivery 
queue for which there is a distribution. 


Signal SERVER_MGR with INCREMENT _OBJ_LOCK to increment the agent lock count for the server 
object. If no server object exists, SERVER_MGR returns OBJECT_OK. 


Signal QUEUE_MGR with WRITEQ to place the distribution on the local-delivery queue. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the agent lock count for the server 
object. If no server objects exists, SERVER_MGR returns OBJECT_OK. 


Add exception to exception-user information. Signal FSM_NEXT_LOCAL QUEUE with 
FIND NEXT _QUEUE_ID to determine the next local-delive: y queue for wh'ch there is a distribution. 


f Signal FSM_SCHED_MGR with START_REQUEST to schedule the destination agent. 
Signal QUEVE_MGR with DEQ to remove the distribution from the local-delivery queue. 


Signal FSM_COUNT_EXCEPTS with COUNT_SCHED_ EXCEPTS to determine if exceptions existed in 
any of the local scheduling process. 


Signal FSM_DIRECTING MGiR with LOCAL_SCHED_COMPLETE_EXPTS to signal directing that 
exceptions existed in the local scheduling process. 


Signal QUEVE_MGR with RELEASEQ to remove the in-use mark from the queue entry in the local- 
delivery queue. The entry will then be available to the destination agent for processing. 
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Routing FSMs 
FSM_ROUTING MGR 


The routing manager sequences the runelens necessary to put a distribution on 
one or more next-DSU queues for transmission to adjacent DSUs. The input to 
this machine is the destination list. The output depends on whether there are 
any local DSUs in the destination list. 


The routing manager generates two main processing sequences: 


e When the routing manager determines that at least one local DSU is in the 
destination list, it signals DIRECTING REQUIRED to 
FSM_ROUTING_DIRECTING_MGR, The output is the distribution with all the 
local destinations marked in the destination list. 


¢ When the routing manager determines that no local DSUs are in the desti- 
nation list, it sequences the routing table lookup, fan-out functions, and the 
enqueuing and scheduling functions. In this case, all copies of the distrib- 
ution are put on the appropriate next-DSU queues. 


The routing manager is aware of two kinds of exceptions: routing table lookup 
exceptions and scheduling exceptions. If routing table lookup exception condi- 
tions exist for all the destination DSUs, the routing manager machine signals 
the operations manager to process the exceptions and terminates processing. 
If exception conditions exist for only some of the DSUs, the routing manager 
handles the exceptions by a signal to the operations manager, and then tries to 
enqueue and schedule the distribution for the non-exception destinations. In 
the case of exceptions reported by FSM_REMOTE_SCHED, the routing manager 
passes the exception list to the operations manager. It assumes that all the 
non-exception copies of the distribution have been enqueued and scheduled. 
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Function: This finite-state machine describes the functional processing in routing. For a further 
description, see “FSM_ROUTING_ MGR” on page 136. 


This FSM gets control from one of the following: 


¢ Signals from higher-level routing and directing finite-state machines: 


— ALL_LOCAL from FSM_ROUTING_DIRECTING_MGR 
— ROUTE from FSM_ROUTING_DIRECTING_MGR 


Signals from lower-level routing and directing finite-state machines: 


ALL_REMOTE from FSM_DSU_CHECK 
AT_LEAST_ONE LOCAL from FSM_DSU_CHECK 
RTG_LOOKUP_COMPLETE from FSM_RTG_LOOKUP 
RTG_LOOKUP_COMPLETE_EXPTS from FSM_RTG_LOOKUP 
RTG_LOOKUP_COMPLETE_ALL_EXPTS from FSM_RTG_LOOKUP 
REMOTE_SCHED_ COMPLETE from FSM_REMOTE SCHED 
REMOTE SCHED COMPLETE_EXPTS from FSM_REMOTE_SCHED 


Signals from finite-state machines providing common services: 
— OPERATIONS_COMPLETE from FSM_OPERATIONS_MGR 
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Signal FSM_DSU_ CHECK with CHECK_LOCAL_REMOTE to determine if both local and remote desti- 
nations exist in the distribution. 


Signal FSM_RTG_LOOKUP with FIND _NEXT_DSU to determine the next DSU connection information 
for the destination DSUs in the distribution. Hop counts are set if the DSU is the origin, or decre- 
mented and validated if the DSU is not the origin. 


Signal FSM_ROUTING DIRECTING MGR with DIRECTING REQUIRED to indicate that destinations 
local to the DSU exist, and require local delivery or redirection. 


Signal FSM_REMOTE_SCHED with REMOTE_DISTRIBUTIONS to schedule the sending of distributions 
to next DSUs. 


Signal FSM_OPERATIONS_MGR with ROUTING DIRECTING EXCEPT to notify the operator, generate 
any requested reports, and log. 


Signal FSM_ROUTING DIRECTING MGR with ROUTING COMPLETE to indicate that all remote desti- 
nations in the distribution have been fanned-out and the resulting distributions have been scheduled 
for sending to the next DSUs. 


Signal FSM_ ROUTING DIRECTING MGR with ROUTING_RESET to indicate that routing has been 
reset. 
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FSM_REMOTE_SCHED 
This machine performs the sequence of functions necessary to enqueue a dis- 
tribution for transmission to a remote destination. Its input is the distribution, 
and, in particular, the destination list. Its output is a list of DSUs that could not 
be sent, and copies of the distribution put on the correct next-DSU queues. It 
causes DS_Send to gain control to transmit the queued distributions. 


For each next-DSU queue name in the list associated with the distribution, 
FSM_REMOTE_SCHED does the following: 


e Requests a next-DSU queue name and a copy of the distribution from 
FSM_NEXT_DSU. 


e Requests that the server manager increment the DS lock count for the 
server object. This creates a lock on the server object for each copy of the 
distribution that must be transmitted. 


e Requests that the queue manager put a copy of the server object on the 
named next-DSU queue. 


e Requests that the scheduler start DS_Send, as appropriate to the sched- 
uling algorithms. 


If an exception occurs, the operations that have been performed on the distrib- 
ution up to that point are reversed. FSM _REMOTE_SCHED adds the exception 
DSUs to a list that it passes back to the routing manager machine. In general, 
if, during the exception recovery process, another exception occurs, it is noted, 
but no other action is taken. 


When FSM_REMOTE_SCHED has no more next-DSU queues to which to route 
the distribution, it signals FSM COUNT EXCEPTS to check whether the excep- 
tion list is empty. 


If it is not empty, FSM_REMOTE_SCHED signals the routing manager machine 
with REMOTE_SCHED_COMPLETE_EXCEPTS so that the routing manager can 
signal operations. Otherwise, FSM_REMOTE_SCHED signals 
REMOTE_SCHED_COMPLETE. 


Although it is not shown in this machine, for an unsuccessful server, queue, or 
scheduling function, FSM_ OPERATIONS MGR should also receive a 
MESSAGE_TO_OPERATOR signal and the message that the function could not 
be completed and that in handling the exception, another exception occurred. 
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Function: This finite-state machine describes the functional processing for remote destinations in routing. 
| For a further description, see “FSM_REMOTE_SCHED” on page 140. 


This FSM gets control from one of the following: 
¢ Signals from higher-level routing and directing finite-state machines: 
= REMOTE_DISTRIBUTIONS from FSM_ROUTING_MGR 
¢ Signals from lower-level routing and directing finite-state machines: 


— NEXT_DSU from FSM_NEXT_DSU 

— END_NEXT_DSUS from FSM_NEXT_DSU 

— SCHED_NO_EXCEPTS from FSM_COUNT_EXCEPTS 
— SCHED_EXCEPTS from FSM_COUNT_EXCEPTS 


¢ Signals from finite-state machines providing common services: 


— OBJECT_OK from SERVER_MGR 

— OBJECT _NOT_OK from SERVER_MGR 

— QUEUE_OK from QUEUE_MGR 

— QUEUE_NOT_OK from QUEUE_MGR 

— SCHED _FUNCTION_OK from FSM SCHED MGR 

— SCHED FUNCTION NOT_OK from FSM_SCHED_MGR 
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Output 
Code 


f 


hi 


Signal FSM_NEXT_DSU with FIND_NEXT_DSU to determine the next DSU for which there is a distrib- 
ution. 


Signal SERVER_MGR with INCREMENT_OBJ_LOCK to increment the DS lock count for the server 
object. If no server object exists, SERVER_MGR returns OBJECT_OK. 


Signal QUEVE_MGR with WRITEQ to place the distribution on the next-DSU queue. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count for the server 
object. If no server object exists, SERVER_MGR returns OBJECT_OK. 


Add exception to exception-user information. Signal FSM_NEXT_DSU with FIND _NEXT_DSU to deter- 


mine the next DSU for which there is a distribution. 


Signal FSM_SCHED_MGR with START_REQUEST to schedule the DS_Send transaction program to 
send distributions to the next DSU 


Signal QUEVE_MGR with DEQ to remove the distribution from the next-DSU queue. 

Signal FSM_COUNT_EXCEPTS with COUNT_SCHED_EXCEPTS to determine if exceptions occurred in 
any part of the remote scheduling process. 

Signal FSM_ROUTING_MGR with REMOTE_SCHED_COMPLETE to indicate to routing that the remote | — 
scheduling process was completed successfully. 


Signal FSM_ROUTING_ MGR with REMOTE_SCHED_COMPLETE_EXPTS to indicate to routing that 


exceptions occurred in the remote scheduling process. 


Signal QUEVUE_MGR with RELEASEQ to remove the in-use mark from the queue entry in the 
next-DSU queue. The entry is then available to DS_Send for processing. 
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Routing and Directing Utility FSMs 
FSM_ORIGIN_CHECK 


This FSM determines whether the distribution passed to it originated locally or 
at a remote DSU, and whether user destinations are present. 

FSM_ORIGIN CHECK reports the results of this operation to 

FSM_ROUTING DIRECTING MGR by signalling either 

ORIGIN REQUEST _USER_NAMES if the distribution originated at the local DSU 
and if at least one user name is in the destination list. It returns 

ORIGIN REQUEST _NO_USER_NAMES if the distribution originated at the local 
DSU, but the destination list includes only node destinations. It returns 
NOT_ORIGIN REQUEST otherwise. FSM_ROUTING DIRECTING MGR decides 
on the basis of these signals whether to signal the directing manager or the 
routing manager first. 


FSM_DEST_DSU_CHECK 
This FSM determines whether any destinations remain in the distribution to be 
serviced. FSM_ROUTING DIRECTING MGR manager signals this machine after 
the directing manager is finished in order to decide whether to signal the 
routing manager. If the destination list is empty, the directing manager has 
delivered the distribution locally, and no recipients remain. In this case, it 
signals NO DEST DSUS_ REMAINING back to FSM_ROUTING DIRECTING MGR. 
If the list is not empty, then there are recipients at remote DSUs to which the 
distribution must be routed. In this case, it signals DEST _DSUS_ REMAINING 
back to FSM_ROUTING_DIRECTING MGR. 


FSM_DIR_LOOKUP | 
If the distribution originated locally, the directory lookup produces DSU names 
for all user names that are not local, and local-delivery queue information for 
the user names that are local. For a distribution that originated at another 
DSU, the directory lookup returns a new DSU name if redirection has taken 
place, or local-delivery queue information if the user name is truly local. 


If the directory lookup produces an exception (for example, ENTRY_NOT_FOUND), 
then the user name producing the exception is recorded. When all the user 
directory accesses are done, the user names producing exceptions and the 
valid user names are returned to the directing manager machine with the signal 
DIR_LOOKUP_COMPLETE_EXPTS. 


If no exceptions are encountered, the destination list is returned with the signal 
DIR_LOOKUP_COMPLETE_NO_EXPTS. 


FSM_LOCAL_ CHECK 
This machine determines from the destination list whether local-delivery queue 
information has been appended. 


In addition, FSM_LOCAL_CHECK makes a copy of the distribution control infor- 
mation for each queue identifier found, and consolidates the user names for 
each queue identifier. That is, only one copy of the distribution is made for 
each queue, and the destination list contains all the destinations associated 
with that queue and service parm. FSM_LOCAL_CHECK also makes a (single) 


144 SNA/Distribution Services Reference 


copy of the server object using the destination server name specified in the dis- 
tribution control information. 


If there is local-delivery queue information, FSM_LOCAL_ CHECK signals 
DIRECTING LOCALS back to the directing manager machine; otherwise, it 
signals DIRECTING NO LOCALS. If an exception was encountered while a 
copy of the server object was being made, this machine signals 
DIRECTING LOCALS COPY_EXPT. 


FSM_NEXT_LOCAL_QUEUE 


This FSM passes the next local-delivery queue identifier and a copy of the dis- 
tribution to FSM_ LOCAL SCHED for processing. The input to this machine is a 
list of local delivery information that corresponds to the local users in the desti- 
nation list, and copies of the distribution, one for each queue identifier. The 
local delivery information is obtained by the FSM_DIR_LOOKUP. The copies of 
the distribution are made by FSM_LOCAL_ CHECK. When the list is exhausted, 
the signal END QUEUE IDS is sent to FSM_LOCAL_ SCHED. 


FSM_COUNT_EXCEPTS 


FSM_DSU_CHECK 


This FSM scans the list of exception destinations created by 

FSM_LOCAL SCHED or FSM_REMOTE_SCHED. If the list is empty, it reports 
SCHED_NO_EXCEPTS to FSM_LOCAL_SCHED or FSM_REMOTE_SCHED. Other- 
wise, it returns the signal SCHED EXCEPTS. It is the mechanism used by the 
scheduling machines to decide whether to signal an exception to the directing 
manager or the routing manager. 


This FSM scans the DSU names in the destination list, and checks them against 
a table containing all the names of the local DSU. The input to this FSM is the 
destination list of the distribution that is being routed. If a match is found, this 
machine signals the routing manager machine with AT_LEAST_ONE_ LOCAL; 
otherwise, it signals ALL_REMOTE. 


FSM_RTG_LOOKUP 


This machine scans the DSU names in the destination list and matches them 
against entries in the routing tables containing the next-DSU queue name and 
connection information. The input that it uses is the destination list of the dis- 
tribution being routed. For each unique next-DSU queue name found, this 
machine associates with it all the DSUs mapped by the routing tables to that 
next-DSU queue. This machine decrements the hop count of the distribution 
copy so that loops in the network can be detected. It also makes a copy of the 
distribution for each unique next-DSU queue name found. The output of 
FSM_RTG_LOOKUP is the next-DSU queue information and the copies of the 
distribution. 


This machine sends three signals back to the routing manager machine. 

RTG LOOKUP_COMPLETE signifies that all DSUs in the destination list have 
been assigned a next-DSU queue. RTG_LOOKUP_COMPLETE_EXPTS means 
that at least one DSU in the destination list could not be assigned a queue, but 
at least one DSU in the list could be assigned a queue, and that it is recorded 
in a list of exception destinations. 
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RTG_LOOKUP_COMPLETE_ALL_EXPTS means that no DSU in the destination 
list could be routed. 


FSM_NEXT_DSU 
This machine scans the list of next-DSU queue names created by 
FSM_RTG_LOOKUP and returns the next queue name and a copy of the distrib- 
ution to FSM_REMOTE_SCHED. The input to this machine is a list of queue 
names corresponding to the remote DSUs in the destination list, and copies of 
the distribution, one for each queue identifier. If no more names are in the list, 
it reports END_NEXT_DSUS back to FSM REMOTE SCHED. 


Distribution Transport Sublayer—Format Set 2 


DS_Send FSMs 


Data Structures 
DS_Send uses the following data structures: 


MU_ID Registry: The MU_ID registry is a safe-stored data structure that 
records MU_/D-to-next-DSU-queue-entry mappings. It may be viewed as an 
array, with each element containing four entries. The first entry is an MU_ID. 
The second is a “distribution locator,” which is used to locate the distribution 
associated with the entry’s MU_ID on any next-DSU queue during error 
recovery processing. The third is the MU_/D state, and the fourth is the current 
instance number. 


MU_IDs are assigned sequentially. Only contiguous blocks of entries in PURGED 
state containing the Registry’s lowest MU_/Ds and null distribution locators may 
be removed from the Registry automatically (and their space reclaimed). All 
other entries must be retained, unless explicitly removed by an operator. 


Queue Entries: Each next-DSU queue entry maintains its MU_ID or a null value 
indicating that no MU_ID has been assigned. 


Program Structure 
A logical decomposition of DS_Send is given in Figure 45 on page 153. The 
following classes of routines exist in DS Send: 


e DS_Send Manager 


The only FSM in this class of routines is “DS_ SEND MANAGER” on 

page 154. It manages the transition between the LU 6.2 send and receive 
states, and also checks for the conversation idle condition, which causes 
the conversation to be deallocated. 


e Send-State Manager 


The only FSM in this class of routines is “DS_SEND_SENDING” on 

page 156. This FSM is active whenever DS_Send is in the LU 6.2 send 
state, and it controls the sending of DMUs and CMwUs to the partner DSU. 
The factors influencing this FSM include not only the MUs queued for the 
partner, but the partner DSU’s flow control wishes (as indicated in the last 
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CRMU). These concepts are discussed in detail in “Throughput Control” on 
page 79. 


Receive-State Manager 


The only FSM in this class of routines is “DS_SEND RECEIVING” on 

page 190. This routine manages DS_ Send while in the LU 6.2 receive state. 
lt repeatedly receives REMUs and CRMUs from the partner, parses them 
and signals the appropriate handler. The terminate_conversation bit from 
the CRMU is passed to the appropriate conversation control routine (even if 
the CRMU contains no MU_ID). Exception conditions (including receiving 
the send indication from the partner) are returned to the caller. 


Distribution Sending 


The only FSM in this class of routines is “DS SEND _SEND_DIST” on 

page 159, which also implements part of the high-integrity actions. The dis- 
tribution sending function requires only getting the distribution from the 
next-DSU queue and then examining it to determine if high-integrity actions 
or basic-integrity actions are required. If basic-integrity actions are 
required, this routine signals DS_SEND SEND _DMU_NO MU_ID. If high- 
integrity actions are required, this routine also assigns the MU_ID (if appro- 
priate), and changes the MU_/D state to IN_TRANSIT before signalling 

DS SEND BUILD_SEND_DMU. 


Control MU Sending 


The only FSM in this class of routines is “DS_SEND_SEND_CONTROL_MU" 
on page 188. This routine is called repeatedly to read the next CMU from 
the control MU queue, send it, and discard it. If an exception occurs, the 
MU is not discarded, but is left on the queue to be resent later. 


REMU Receiving 


The only FSM in this class of routines is “DS SEND REMU_HANDLER” on 
page 204. This routine handles REMUs. The actions taken for a particular 
REMU depend on the status of the distribution (not found, retriable with a 
new MU_ID, or restartable with a DCMU), the MU_ID state 
(TRANSFER_PENDING, CQMU_PENDING, etc.), and the exception classification (not 
retriable or retriable). Potential actions include 


— Querying the partner to determine the Mid-MU Restart position. 

— Purging the MU_ID and retrying the distribution with a new MU_ID ata 
later time. 

— Terminating the distribution. 


REMUs with old instance numbers are simply discarded, as are REMUs 
reporting already-detected conversation failures and REMUs with no MU_ID. 


CRMU Receiving 


The only FSM in this class of routines is “DS_SEND_CRMU_HANDLER” on 
page 192. This routine processes the values from the CRMU’s MU_ID state 
indication. The specific actions taken for a given distribution and CRMU 
depend on DS _Send’s MU_ID state, the partner’s MU_ID state as reported in 
the CRMU, and DS_Send’s ability to re-attempt the transmission (with or 
without mid-MU restart). The actions include 
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— Purging the distribution because the partner has accepted responsi- 
bility. | 
— Marking the distribution to be restarted later using a DCMU. 

— Purging the MU_ID and retrying the distribution with a new MU_ID ata 
later time. _ | 
— Querying the partner for an updated MU_/D state. 

— Reissuing a lost SEMU. 

— [Issuing a SEMU to recover from a lost DMU. 
— Reissuing a lost PRMU. 

— Terminating the distribution. | 


CRMuUs with old instance numbers are simply discarded. 
e Basic-Integrity Actions 


The only FSM in this class of routines is 
“DS_SEND_SEND_DMU_NO _MU_ID” on page 181. It builds and sends to 
the partner the basic-integrity distribution MU. When the suffix has been 
sent, the distribution is discarded. Exceptions are handled by 

“DS SEND_EXCEPT_NO MU_ID” on page 185. 


¢ High-Integrity Actions 


These routines associate an MU_ID to a distribution, set the MU_ID state to 
IN TRANSIT, encode the distribution into the appropriate DMU (DTMU, DCMU 
or DRMU), send it to the partner, and (in the absence of exception condi- 
tions) set the MU_ID state to TRANSFER_PENDING. 


The FSMs in this class are: 
— “DS SEND_SEND_DIST” on page 159. 


This routine also implements the distribution sending function discussed 
above. The high-integrity actions it performs are to assign the dis- 
tribution’s MU_ID, if appropriate, and set the MU_ID state to IN_TRANSIT. 
It then signals DS_SEND_BUILD_SEND_DMU, which processes the dis- 
tribution and returns the results of the transmission. 


— “DS SEND BUILD SEND _DMU” on page 163. 


This routine encodes the distribution, reads the server object and sends 
the DMU to the partner DSU. Immediately before sending the suffix, it 
also changes the MU_ID state to TRANSFER_PENDING. Exceptions 
encountered during processing are passed to the appropriate 
exception-handling FSM. After the suffix has been sent, 

DS SEND _CLEANUP_DMU is signalled to perform the required post- 
transmission processing. 


— “DS _SEND_CLEANUP_DMU” on page 166. 


This FSM simply replaces the distribution on the next-DSU queue. 
Exceptions cause the appropriate exception-handling FSM to be sig- 
nalled. 
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e Pre-Sending Exception Actions 


The only FSM in this class of routines is 

“DS_SEND DMU EXCEPT NOT SENDING” on page 168. Exceptions occur- 
ring before the DMU’s prefix is passed to LU 6.2 are known as pre-sending 
exceptions. There are three types of pre-sending exceptions: 


— A queue exception occurs on the READQ that gets the distribution from 
the next-DSU queue. 

— An MU_ID registry exception occurs on the inspection of the MU_ID 
State. 

— An MU_ID registry exception occurs when a new MU_ID is assigned to 
the distribution or an existing MU_ID state is set to IN_TRANSIT. 


All three exceptions result in the next-DSU queues being held, which pre- 
vents any other distribution transmissions from being attempted. When 
queue exceptions are encountered, CMU traffic continues, if possible; 
MU_ID registry exceptions cause the immediate termination of DS_ Send. 


» REMU Actions 


The actions that may be performed in response to a REMU are listed above, 
under “REMU Receiving.” The FSMs in this class are: 


“DS_SEND_QUERY_ON_REMU” on page 208. 


This FSM is signalled when a REMU reporting a retriable exception is 
received, mid-MU restart is possible, and the sender’s MU_ID state is 
either TRANSFER_PENDING Or RETRY_PENDING. In the former case ({i.e., the 
sender’s MU_ID state is TRANSFER_PENDING), DS_Send completed 
sending the distribution before receiving the partner’s Prog Error indi- 
cation. In the latter case, DS_ Send received the Prog Error indication 
while sending the DMU, and set the MU_ID state to RETRY_PENDING in 
anticipation of receiving a REMU that reported a retriable exception. 


This FSM retains the distribution (i.e., it signals 
DS_SEND_RETAIN_ DIST), holds the next-DSU queues, sets the MU_/ID 
state to CQMU_PENDING, and issues a CQMU to query the partner. 


— “DS SEND _RETRY_ON REMU” on page 210. 


This FSM is signalled when the distribution in question is to be retried 
with a new MU_ID. To state these conditions more precisely, 
DS_Send’s MU_ID state is TRANSFER_PENDING, CQMU_PENDING or 
RETRY_PENDING, mid-MU restart via a DCMU is not available, and the 
REMU from partner reports a retriable exception. 


Preparing a distribution for retry with a new MU_/D involves purging the 
(existing) MU_ID from the registry, sending a PRMU, and marking the 
distribution as having no MU_ID. The next-DSU queues are also held. 


— “DS _SEND_CHECK_CONV FAIL” on page 212. 


This FSM determines if a just-received REMU is reporting an already- 
detected conversation failure. Conversation failures may cause the loss 
of a partial or complete MU, and are unusual in that the affected 
MU_IDs might be detected by either, neither, or both DS_Send and 

DS_ Receive. Because either DS_ Send or DS_Receive may be the only 
detector of the failure, they both initiate exception recovery actions by 
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sending a SEMU or REMU (respectively). This leads to the conversation 
failures that are detected by both DS_Send and DS_ Receive being 
reported by both a SEMU and a REMU. In such cases, the SEMU is pre- 
ferred and the REMU is discarded. 


(If an MU_ID affected by a conversation failure is detected by neither 
DS Send nor DS Receive, then either or both of the DSUs will eventu- 
ally grow impatient at the MU_ID state being active. If DS Receive 
grows impatient, it will send an unsolicited CRMU; if DS Send grows 
impatient, it will send a CQMU.) 


This FSM is called whenever the just-received REMU might be redun- 
dant, and returns either an indication that the REMU is redundant (and 
has thus been discarded) or the recovery action (Not Retriable, 
Retriable With Mid-MU, Retriable Without Mid-MU, or Retriable Retry 
Exhausted). 


e Shared REMU/CRMU Actions 


The only FSM in this class of routines is “DS_SEND_TERMINATE_DIST” on 
page 214. It is called when a REMU or CRMU is received and DS_Send 
determines that an exception condition makes reattempting transmission of 
the distribution inappropriate. Terminating a distribution involves the fol- 
lowing actions: 


— Holding the next-DSU queues (if requested to do so), 
— Generating a distribution report (if appropriate), 

— Setting the MU_/ID state to PURGED, 

— Signalling DS SEND _DISCARD_DIST. 

— Generating a PRMU to the partner. 


¢ CRMU Actions 


The actions that may be performed in response to a CRMU are listed 
above, under "CRMU Receiving.” The FSMs in this class are: 


“DS SEND RELEASE_ON CRMU” on page 196. 


This FSM is signalled under a variety of conditions and with a variety of 
input conditions, but its primary function is simply to release the distrib- 
ution for later processing. A CQMU is generated, if requested. 


— “DS_SEND_PURGE_ON_CRMU” on page 198. 


This FSM is signalled when the partner DSU accepts responsibility for 
the distribution (i.e., a CRMU(COMPLETED) is received), or when a PRMU 
has been lost and a new PRMU must be generated. It changes the 
MU_ID state to PURGED and issues a PRMU to the partner. If requested, 
the distribution is also discarded. 


—- “DS_SEND_RETRY_ON_CRMU” on page 200. 


If a distribution’s transfer to the partner is interrupted by an exception, 
DS Send determines whether to terminate the distribution or to attempt 
to recover from the exception. If DS_Send decides to attempt recovery, 
this FSM is signalled. It either suspends the distribution by setting the 
MU_ID state to SUSPENDED, or it purges the MU_ID and prepares the dis- 
tribution to be retried later with a new MU_ID. 
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—- “DS_SEND_ISSUE_SEMU_ON CRMU” on page 202. 


This FSM issues a SEMU and releases the distribution for further proc- 
essing. It is called when DS Send perceives a lost SEMU, or DMU. 
Lost SEMUs are merely regenerated. 


e Basic-Integrity Exception Actions 


The only FSM in this class of routines is “DS_SEND EXCEPT NO MU_ID” 
on page 185. It is signalled to process all exception conditions encountered 
during the transmission of basic-integrity distributions. Depending on the 
exception, the distribution is either discarded or retained to be retried 
(without mid-MU restart) later. The next-DSU queues are held, if appro- 
priate. 


e High-Integrity Exception Actions 


These FSMs handle the exception conditions detected in 
“DS_ SEND BUILD SEND DMU” on page 163. The FSMs in this class are: 


“DS SEND_DMU_ENCODE EXCEPT” on page 170. 


This FSM is signalled by DS_SEND BUILD SEND _DMU and handles 
builder or server exceptions encountered after the first Send Data LU 
6.2 verb has been issued. A Send Error LU 6.2 verb is issued, and 
DS_SEND_CLEANUP_EXCEPT is signalled to process the distribution 
and MU_ID. 


—- “DS_SEND_CLEANUP_EXCEPT” on page 172. 


This FSM is signalled by DS_SEND_BUILD_SEND_DMU when an excep- 
tion is encountered while building the first part of a DMU, or when a 
conversation failure is detected. It is also signalled by 

DS SEND _DMU ENCODE EXCEPT. This FSM 


— Retains the distribution with or without holding the next-DSU 
queues, as appropriate. 

— Sets the MU_ID state to TERMINATION_PENDING Or RETRY_PENDING, as 
appropriate. 

— Issues a SEMU to the partner describing the exception. 


— “DS SEND PROG ERROR RECEIVED” on page 174. 


This FSM is signalled whenever a Prog Error indication is received from 
LU 6.2. It retains the distribution (without holding the next-DSU queues), 
and sets the MU_ID state to RETRY_PENDING. 


—- “DS SEND _DMU_PROTOCOL_ERROR” on page 176. 


This FSM is signalled if, while transmitting a DMU, DS_Send detects the 
partner DSU violating the DS usage of the LU 6.2 basic conversation 
protocol boundary. In this model, the affected distribution is retained, 
the MU_ID state set to TERMINATE_PENDING and the conversation imme- 
diately deallocated. Instead of merely deallocating the conversation, 
implementations may issue a Send Error LU 6.2 verb, generate a 
SEMU, flush their control MU queue, and deallocate the conversation. 
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— “DS SEND MU_ID STATE _ERROR” on page 178. 


This FSM is signalled if the MU_/ID state cannot be set to 
TRANSFER_PENDING before the suffix is sent to the partner. The distrib- 
ution is retained and the next-DSU queues are held. 


¢ DS Send Utility Routines 


These utilities are signalled by many of the DS_Send FSMs. The FSMs in 
this class are: 


“DS SEND RETAIN DIST” on page 216. 


When processing on a distribution is halted temporarily, this FSM is sig- 
nalled to terminate any server operations in progress and to clear the 
distribution’s in-use mark, making the distribution available for further 
processing. Retaining a distribution involves the following actions: 


— Holding the next-DSU queues, if requested. 

— Issuing a Terminate_Read verb to the server. The restartability of 
the server (if originally requested) is maintained. 

— Signalling the queue manager with RELEASEQ to remove the in-use 
mark from the distribution. The distribution will then be available to 
other DS_Send processes. 


— “DS_SEND_DISCARD_DIST” on page 218. 
Discarding a distribution involves the following actions: 


— Deleting the server object for this distribution, if one exists. This 
involves: 
e Issuing the Terminate_Read server verb if the server object was 
being read. 
e Issuing the Terminate_Restartability server verb if restartability 
had been requested. 
« Decrementing the DS lock count for the server object. 
— Signalling the queue manager with DEQ to remove the distribution 
from the next-DSU queue. 


— “DS SEND CONVERSATION CONTROL” on page 222. 


This FSM records what DS_Send may send to the partner DSU at any 
particular time. For example, DS_ Send 


— May be able to send only control MUs, 

— May be able to send both control MUs and a single distribution MU, 

— May be required to terminate the conversation after any waiting 
control MUs have been sent. 


— “DS_SEND_SEND_CONVERSATION_ MGR” on page 220 


This FSM sends a single buffer to the partner DSU by issuing an LU 6.2 
Send_Data verb. The outcome of the Send_Data {i.e., LU 6.2 accepted 
the data without detecting an exception, a conversation failure was 
detected, or the partner DSU issued a Send _ Error) is returned to the 
caller. 
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— “DS SEND MU_ID_REGISTRY” on page 223 


This procedure manages DS_Send’s access to the MU_ID registry. An 
MU_ID state may be assigned or inspected, or a just-received instance 
number may be compared to the instance number in the registry. (MUs 
containing an instance number lower than the registry’s are ignored.) 


— “UPM_CHECK DUP_CONV_FAIL_REPORT” on page 224 


As discussed earlier (see the discussion for 
DS_SEND_CHECK_CONV FAIL above, under “Program Structure” on 
page 146), some conversation failures cause both DS_Send and 
DS_Receive to initiate exception processing for the same MU_/ID. This 
procedure is signalled by DS_ SEND CHECK CONV FAIL to determine if 
a given REMU does or does not represent such a duplicate (and extra- 
neous) exception report for an already-known conversation failure. 


Send-State Recejive-State 
Manager Manager 
Distribution Control] MU REMU 
MU Sending Sending Receiving 


Basic- High- Pre-Sending REMU Shared CRMU 
Integrity Integrity Exception Actions REMU/CRMU Actions 
Actions Actions Actions Actions 


CRMU 
Receiving 


Basic- Hi gh- 
Integrity Integrity 
Exception Exception 
Actions Actions 


Figure 45. DS Send Logical Structure 
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DS_SEND MANAGER 


Function: This finite-state machine describes the functional processing for DS Send. It is started by the 
DS_Router_Director via a START_TRANSACTION signal, by LU 6.2 on receiving an Attach, or 
by the operator via START_TRANSACTION. If DS Send is started by LU 6.2 via Attach, it is 
initially in the LU 6.2 receive state. Otherwise, it is initially in the LU 6.2 send state. 


The primary processing of this FSM is done in states 4 (SEND), 5 (RCV) and 6 (IDLE). When in 
RCV state (state 5), DS_Send is in the LU 6.2 receive state and is receiving control MUs from 
the partner. If DS_Send then receives the change direction indication from LU 6.2, it imme- 
diately attempts to send any waiting MUs to the partner by signalling DS_SEND_SENDING. 


When in SEND state (state 4), DS_Send is in the LU 6.2 send state, and is sending MUs to the 
partner. The lower-level FSMs signal DS_Send to enter the LU 6.2 receive state by returning 
CHANGE_DIRECTION. DS_ SEND MANAGER first checks to determine if an idle conversation 
exists by signalling IDLE_DETECTOR. If an idle conversation does exist, the conversation is 
simply deallocated. If the conversation is not idle, DS_Send goes into the LU 6.2 receive state 
by signalling DS_SEND_RECEIVING. 


An idle conversation exists whenever both of the following conditions hold: 


¢ When DS_Send was last in the LU 6.2 receive state, it received no CMUs from the partner. 
¢ DS_Send, which is currently in the LU 6.2 send state, has no MUs (distribution or control 
MUs) to send to the partner DS _ Receive. 


Note: Upon detecting a conversation failure, implementations attempt to reactivate the session once. 
This FSM gets control from one of the following: 
¢ Signals from higher-level finite-state machines or procedures: 


— from “FSM _SCHED_MGR” on page 351 
— START_TRANSACTION 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS _SEND_ SENDING” on page 156 
— CHANGE_DIRECTION 
— DEALLOC_LOCAL 
— DEALLOC_ABEND 
— DEALLOC_FLUSH 
— from “DS _SEND_RECEIVING” on page 190 
— CHANGE_DIRECTION 
— DEALLOC_LOCAL 
— DEALLOC_FLUSH 
— DEALLOC_ABEND 


¢ Signals from machines providing common services: 


— from “IDLE_DETECTOR” on page 284 
— CHANGE_DIRECTION 
— DEALLOC_FLUSH 


¢ Signals from LU 6.2 presentation services 


— ATTACH 

— OK 

—- ALLOC_PARM_ERROR 
— ALLOCATION_ERROR 
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Signal LU 6.2 presentation services with ALLOCATE to establish the conversation with DS_Receive. 


Signal LU 6.2 presentation services with GET_ATTRIBUTES to determine the LU name and mode 
name of the partner 


lc «| Signal DS_SEND_SENDING with START. 
id | Notify operations of the exception condition. 


Notify operations of the exception condition. 
Signal LU 6.2 presentation services with DEALLOCATE specifying type(LOcAL). 


Signal DS_SEND_RECEIVING with START. 
Signal IDLE_DETECTOR with CHANGE_DIRECTION. 


h Signal LU 6.2 presentation services with DEALLOCATE specifying type(LOcaL). 


—_———- Signal LU 6.2 presentation services with DEALLOCATE specifying type(FLUsH). 
ae Signal LU 6.2 presentation services with DEALLOCATE specifying type(ABEND). | 
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DS_SEND_SENDING 


Function: This finite-state machine describes the functional processing for DS_ Send while in the LU 6.2 
send state. It first checks the flow control status of the connection, which will be “send control 
MU,” ’send distribution,” or 7terminate conversation.” If no control MUs are waiting and the 
flow control status is “send distribution,” then a distribution (DTMU, DRMU, or DCMU) is sent. 
The above sequence is repeated until the caller is signalled either to change direction, or deal- 
locate the conversation. 


Multiple CMUs may be sent both immediately before and after the distribution, before the 
change direction. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS SEND MANAGER?” on page 154 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS SEND_CONVERSATION_CONTROL” on page 222 
— SEND _CONTROL_MU 
— SEND_DISTRIBUTION 
— TERMINATE_CONVERSATION 
— from “DS SEND _SEND_CONTROL_MU” on page 188 
— CONTROL_MU_SENT 
— CONTROL_MU_QUEUE_EMPTY 
— PROTOCOL_ERROR 
— CONVERSATION_FAILURE 
— DS _SEND_SYSTEM_ERROR 
— PROG_ERROR 
— from “DS_SEND_SEND_DIST” on page 159 
— DISTRIBUTION COMPLETE 
— DISTRIBUTION _QUEUES_EMPTY 
— PROTOCOL_ERROR 
— CONVERSATION _ FAILURE 
— SEND_SIDE_EXCEPT 
— PROG_ERROR 
— DS _SEND_SYSTEM_ERROR 
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Signal caller with DEALLOCATE_ABEND for protocol or system errors. 
Signal caller with DEALLOCATE_LOCAL. | 
Signal caller with DEALLOCATE_FLUSH. 
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oo 


DS _SEND_SEND_DIST 


Function: 


This finite-state machine initiates the transmission of a distribution to the partner. If the distrib- 
ution requires only basic integrity, then DS SEND SEND DMU_NO_MU_ID is signalled to 
transmit the distribution. If high integrity is required, then the MU_/D state is changed to 
IN_TRANSIT, and DS_SEND_BUILD_SEND_DMU is signalled. 


A failure on the initial READQ will cause a HOLD to be placed on the next-DSU queues and a 
SEND_SIDE_EXCEPT to be returned to the caller, who will continue sending CMUs. Eventually, 
all CMUs will be transmitted and this routine will again be called to send a distribution. At this 
point, the HOLD placed on the next-DSU queues will cause this routine to return 
DISTRIBUTION_QUEUES_EMPTY. 


This FSM gets control from one of the following: 
* Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_SENDING” on page 156 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS SEND DMU_EXCEPT_NOT SENDING” on page 168 
— SEND SIDE EXCEPT 
— from “DS SEND SEND DMU_NO MU _ID” on page 181 
— PROG ERROR 
— CONVERSATION FAILURE 
— PROTOCOL. ERROR 
— SEND SIDE EXCEPT 
— DISTRIBUTION COMPLETE 
— from “DS SEND BUILD SEND DMU” on page 163 
— PROG ERROR 
— CONVERSATION FAILURE 
— PROTOCOL. ERROR 
— SEND SIDE EXCEPT 
— DISTRIBUTION COMPLETE 
— DS SEND SYSTEM_ERROR 
— from “DS SEND _MU_ID REGISTRY” on page 223 
— NOT_ASSIGNED 
— SUSPENDED 
— MU_ID_NOT_USED 
— MU_ID OP_OK 
— MU_ID OP _NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE _MGR’” on page 357 
— QUEUE OK 
— QUEUE_EMPTY 
— QUEUE NOT_OK 


Chapter 3. Implementation Model 159 


MU_ID 
RESET RDQ DIST STATE PROC DMU 


QUEUE EMPTY ee 


QUEUE NOT OK 
SUSPENDED 

MU ID NOT USED 

MU ID OP OK 

MU ID OP NOT OK 
ERROR 
CONVERSATION FAILURE 
PROTOCOL ERROR 
DISTRIBUTION COMPLETE 
SEND SIDE EXCEPT 

DS SEND SYSTEM ERROR 


~ 


| 
~~ 
} 
; 


| 
i 
i i 
i i 
\ ‘ 
i 
i 


ee ee ee ae ee 


{ 
{ 
: 
i 
| 
\ 
{ 
{ 
i 
i 
| 
\ 
| 
| 
i 
{ 
H 
| 
| 
i 


and 
— 


460  SNA/Distribution Services Reference 


Output 
Code 


Signal QUEUE_MGR with READQ specifying queuve(NEXT-DSU-QUEUE) 
where_MU_ID_state_is(NOT_ASSIGNED, or SUSPENDED) to get the next distribution to be sent. The HOLD 
flag is respected for this operation; if the HOLD indication is set for this queue, QUEUE MGR returns 
QUEUE_EMPTY, even if other queue exception conditions are present. 


Signal DS_SEND_MU_ID_REGISTRY with INSPECT. If the distribution uses basic integrity, processing 
continues with the MU_ID_NOT_USED input. 


Signal caller with DISTRIBUTION_QUEUES_EMPTY. 
Signal DS_SEND_DMU_EXCEPT_NOT_SENDING with QUEUVUE_ACCESS_ EXCEPT. 
Signal DS_SEND_MU_ID_REGISTRY with ASSIGN. 


Signal DS_SEND MU_ID_REGISTRY with IN_TRANSIT to set the MU_/D state and update the instance 
number. 


k Signal caller with CONVERSATION_FAILURE to indicate that an error has occurred in the conversa- 
tion between DS_Send and DS_ Receive. 


Signal caller with PROTOCOL_ERROR. 


Signal caller with DISTRIBUTION_COMPLETE to indicate that the MU has been encoded and sent to 
DS_ Receive. 


Signal caller with SEND_SIDE_EXCEPT. 
Signal caller with DS_SEND_SYSTEM_ERROR. 
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DS_SEND_ BUILD _SEND_DMU 


Function: 


This finite-state machine encodes and sends a high-integrity distribution. States 3 and 4 are a loop which 


builds and sends the distribution pieces. States 4, 5 and 6 are a loop which reads, builds and sends the 


server object pieces Before sending the suffix, the MU_ID state is changed to TRANSFER_PENDING. 


This FSM gets control from one of the following: 


Signals from higher-level finite-state machines or procedures: 


— from “DS_SEND_SEND_DIST” on page 159 
— START 

— from the operator 
— OP_SUSP 


Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_SEND_CONVERSATION_MGR” on page 220 
— OK 
— PROG_ERROR 
— PROTOCOL_ERROR 
— CONVERSATION_FAILURE 
— from “DS_SEND_CLEANUP_DMU” on page 166 
— DISTRIBUTION COMPLETE 
— SEND_SIDE_EXCEPT 
— from “DS_SEND_DMU_ENCODE_EXCEPT” on page 170 
— PROG_ERROR 
— CONVERSATION_FAILURE 
— PROTOCOL_ERROR 
— SEND_SIDE_EXCEPT 
— DS_SEND_SYSTEM_ERROR 
— from “DS_SEND_PROG_ERROR_RECEIVED” on page 174 
— PROG_ERROR 
— from “DS_SEND_DMU_PROTOCOL_ERROR” on page 176 
— PROTOCOL_ERROR 
— from “DS_SEND_CLEANUP_EXCEPT” on page 172 
— DS_SEND_SYSTEM_ERROR 
— SEMU_SENT 
— from “DS_SEND_MU_ID_STATE_ERROR?” on page 178 
— DS_SEND_SYSTEM_ERROR 
— SEMU_SENT 
— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 


Signals from machines providing common services: 


— from “IDLE_DETECTOR” on page 284 
— no signals returned from this FSM. 
— from “SERVER_MGR” on page 354 
— OBJECT OK 
— NO_OBJECT_EXISTS 
— OBJECT _EOD 
— OBJECT _NOT_OK 


from “BUILDER” on page 359 


— BUILD OK 
— BUILD OK _GET_OBJECT 
— BUILD COMPLETE 

— BUILD_NOT_OK 
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Output 
Code 
Signal BUILDER with BUILD to start or continue building the DTIMU, DRMU or DCMU. 


Signal IDLE_DETECTOR with SOMETHING_SENT. 
Signal DS_SEND_SEND_CONVERSATION_MGR with SEND_BUFFER to send the MU information to LU 
6.2. 


Signal IDLE_DETECTOR with SOMETHING_SENT. 
Signal DS_SEND_MU_ID_REGISTRY with TRANSFER_PEND. 


Signal DS_SEND_CLEANUP_EXCEPT with START to clean up the distribution and generate a SEMU. 
(But no Send_Error will be issued.) 


Signal DS_SEND_PROG_ERROR_RECEIVED with PROG_ERROR_RECEIVED to clean up the distrib- 
ution before handling the PROG_ERROR from the partner DSU. 


Signal DS_SEND_DMU_PROTOCOL_ERROR with PROT_ERROR_DETECTED to clean up the distrib- 
ution before handling the protocol error from the partner DSU. 


Signal DS_SEND_SEND_CONVERSATION_MGR with SEND_BUFFER to send the MU information to LU 
6.2. 


h Signal DS_SEND_MU_ID_REGISTRY with TRANSFER_PEND. 
Signal DS_SEND_DMU_ENCODE_EXCEPT with START to take appropriate error-handling actions. 


Signal SERVER_MGR with READ to read the object and perform any initialization for reading, if not 
yet performed. 


Signal BUILDER with END_OBJECT to indicate that the server has returned EOD and the last 
segment of the object should be built, or, if no object exists, the length of the data will be 0. 


Signal DS_SEND_CLEANUP_DMU with START. 


Signal caller with PROG_ERROR. 


Signal caller with CONVERSATION_FAILURE to indicate that an error has occurred in the conversa- 
tion between DS_Send and DS_Receive. 


Signal caller with PROTOCOL_ERROR. 


Signal caller with DISTRIBUTION COMPLETE to indicate that the MU has been encoded and sent to 
DS_ Receive. 


r Signal caller with SEND_SIDE_EXCEPT 
Signal caller with DS SEND _SYSTEM_ERROR 


Signal DS_SEND_MU_ID_STATE_ERROR with START to clean up the distribution after the failed 


attempt to set the MU_/D state to TRANSFER_PENDING. 
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DS_SEND_CLEANUP_DMU 


Function: This finite-state machine describes the functional processing for tidying up a distribution once it 
has been sent to the partner and the MU_/D state set to TRANSFER_PENDING. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_BUILD_SEND_DMU” on page 163 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 
— from “DS_SEND_RETAIN_DIST” on page 216 


— DIST_RETAINED 
— RELQ_ FAILED 
— TERM_READ_FAILED 
— TERM_READ_RELQ FAILED 
— from “DS_SEND_ CONVERSATION CONTROL” on page 222 
— No signals are returned from this FSM. 


¢ Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE_OK 
— QUEUE NOT_OK 


RESET RETAIN DIST a oon 
Inputs a 


— 


QUEUE NOT OK 
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Signal DS_SEND CONVERSATION CONTROL with DMU_SENT. 
Signal DS_SEND_RETAIN DIST with NO_HOLDQ. 


Chapter 3. 
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Signal caller with DISTRIBUTION COMPLETE to indicate that the MU has been encoded and sent to 
DS_ Receive. 


Signal QUEUE_MGR with HOLD to place an exception-hold on all next-DSU queues for this con- 
nection; no more distributions are sent to the partner DSU. The control MU queue is not held. 


Signal caller with SEND_SIDE_EXCEPT. 
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DS_SEND_DMU_EXCEPT_NOT_SENDING 


Function: This finite-state machine describes the functional processing for non-builder exceptions 
detected in a DMU before any portion of the DMU is transferred to the partner DSU. Pre- 
sending exceptions are of three types: 


¢ A queue exception occurs on the READO that gets the distribution from the next-DSU 
queue. 

¢ An MU_ID registry exception occurs on the inspection of the MU_ID state. 

¢ An MU_ID registry exception occurs when a new MU_ID is assigned to the distribution or 
an existing MU_ID state is set to IN_TRANSIT. 


All three exceptions result in an exception-hold being placed on the next-DSU queues, which 
prevents any distributions from being sent. If this FSM is signalled because of a queue excep- 
tion, and if the next-DSU queue hold operation completes successfully, then 
SEND_SIDE_EXCEPT is returned, and CMUs will continue to be exchanged with the partner. If 
the hold operation on the next-DSU queues fails, or this FSM is signalled because of an MU_ID 
registry exception, DS_SEND_SYSTEM_ERROR is returned, and the conversation is terminated 
immediately. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_SEND_DIST” on page 159 
— REGISTRY_EXCEPT 
— QUEUE ACCESS EXCEPT 


¢ Signals from machines providing common services: 


— from “QUEUE MGR?” on page 357 
— QUEUE OK 
— QUEUE NOT_OK 


REG ERR QUE ERR 
— oan ae ae ar sae 


168  SNA/Distribution Services Reference 


Signal QUEVE_MGR with HOLD to place an exception-hold on all next-DSU queues for this con- 
nection; no more distributions are sent to the partner DSU. The control MU queue is not held. 


Signal QUEVUE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 
queue. Following the RELEASEQ, the entry will be available for processing. 


Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 
Notify operations of the exception condition. 
Signal caller with SEND_SIDE_EXCEPT. 
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DS_SEND_DMU_ENCODE_EXCEPT 


Function: This finite-state machine describes the functional processing for errors detected while the DMU 
is being transferred to the partner DSU. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS SEND BUILD SEND DMU” on page 163 
— START 


Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_CLEANUP_EXCEPT” on page 172. 
— SEMU_SENT 
— DS _SEND_SYSTEM_ERROR 


Signals from LU 6.2 presentation services 


OK | 
ALLOCATION. ERROR 
DEALLOCATE_ABEND 
PROG_ERROR 
SVC_ERROR 
RESOURCE_FAILURE 


SVC ERROR 
ALLOC ERROR 


JDSSEND SySTEMERROR | J |) | td 
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Notify operations of the exception condition. 
Signal caller with PROG_ERROR. 


Notify operations of the exception condition. 
Signal caller with PROTOCOL_ERROR. 
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DS _SEND_CLEANUP_EXCEPT 


Function: This finite-state machine describes the functional processing for cleaning up a distribution after 
an exception has been detected during the MU’s transfer to the partner DSU. This FSM 


¢ Retains the distribution with or without holding the next-DSU queues, as appropriate. 
e Sets the MU_ID state to TERMINATION_PENDING Or RETRY_PENDING, aS appropriate. 
e Issues a SEMU to the partner describing the exception. 


This FSM gets contro! from one of the following: 
e Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_DMU_ENCODE_EXCEPT” on page 170 
— START 

— from “DS_SEND_BUILD_SEND_DMU” on page 163 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 
— from “DS _SEND_RETAIN_ DIST” on page 216 
— DIST_RETAINED 
— RELQ_ FAILED 
— TERM_READ_FAILED 
— TERM_READ_RELQ_FAILED 
— HOLDQ_FAILED 
— HOLDQ_RELQ_FAILED 
— HOLDQ_TERM_READ FAILED 
— HOLDQ_TERM_READ_RELQ FAILED 


¢ Signals from machines providing common services: 


— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITHOUT_MID_MU 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_RETRY_EXHAUSTED 
— from “QUEUE MGR” on page 357 
— QUEUE OK 
— QUEUE NOT_OK 
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QUEUE NOT OK 


Signal UPM_EXCEPT_RECOVERY_ACTION with the exception code. 


Signal DS_SEND_RETAIN_DIST with NO_HOLDQ. 
Signal DS_SEND_MU_ID_REGISTRY with RETRY_PEND. 
Signal DS_SEND_MU_ID_REGISTRY with TERM_PEND. 


Signal DS_SEND_RETAIN_DIST with HOLDQ. 


Build a SEMU describing the exception and signal QUEVUE_MGR with WRITEQ specifying 
queue(CONTROL_MU_QUEUE). Implementations may choose to suppress this SEMU if the exception was 
an LU 6.2 ALLOCATION_ERROR. In this case, processing continues as though QUEUE_MGR returned 
QUEUE_OK. 


Signal caller with SEMU_SENT. 


Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 
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DS SEND _PROG_ERROR_RECEIVED 


This finite-state machine describes the actions taken to suspend the transmission of a distrib- 
ution upon the receipt of a Prog_Error indication from the partner DSU. The distribution is 
retained (without holding the next-DSU queues), and the MU_ID state is set to RETRY_PENDING. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_BUILD_SEND_DMU” on page 163 
— PROG_ERROR_RECEIVED | 


* Signals from lower-level DS_Send finite-state machines: 


— from “DS _SEND_RETAIN_DIST” on page 216 
DIST_RETAINED 
~RELQ_ FAILED 
TERM_READ_FAILED 
TERM_READ_RELQ_FAILED 
HOLDQ_ FAILED 
HOLDQ_RELQ FAILED 
HOLDQ_TERM_READ_FAILED 
HOLDQ_TERM_READ_RELQ FAILED 
from “DS SEND _MU_ID_REGISTRY” on page 223 


— MU_ID OP_OK 
RESET RETAIN DIST | RETRY PEND 


— MU_ID_OP_NOT_OK 


DIST RETAINED 


~~ 
; 


TERM READ FAILED | 
TERM READ RELQ FAILED 
HOLDQ FAILED 
HOLDQ RELQ FAILED a ae ee ae 
HOLDQ TERM READ FAILED 
HOLDQ TERM READ RELQ FAILED | 
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Signal DS_SEND_RETAIN_DIST with NO_HOLDQ. 
Signal DS SEND _MU_ID_REGISTRY with RETRY_PEND. 


Notify operations of the exception condition. 
Signal caller with PROG_ERROR. 

Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 
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DS_SEND_DMU_PROTOCOL_ERROR 


This finite-state machine describes the actions taken if a violation of the DS usage of the LU 6.2 
basic conversation verbs is detected from the partner DSU. The next-DSU queues are held, 
and the MU_ID state changed to TERMINATION_PENDING. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_BUILD_SEND_DMU” on page 163 
— PROT_ERROR_DETECTED 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_RETAIN_DIST” on page 216 
DIST_RETAINED 
RELQ FAILED 
TERM_READ_ FAILED 
TERM_READ_RELQ_FAILED 
HOLDQ_FAILED 
HOLDQ_RELQ_ FAILED 
HOLDQ_TERM_READ_FAILED 
HOLDQ_TERM_READ_RELQ_FAILED 

from “DS_SEND_MU_ID_REGISTRY” on page 223 


— MU_ID_OP_OK 
RESET RETAIN DIST | TERM PEND 


— MU_ID_OP_NOT_OK 


— 


RELQ FAILED 

TERM READ FAILED 
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HOLDQ FAILED 
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Signal DS_SEND_RETAIN_DIST with HOLDQ 


Signal DS_SEND_MU_ID REGISTRY with TERM_ PEND. 


Notify operations of the exception condition 
Signal caller with PROTOCOL_ERROR 


Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 
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DS_SEND_MU_ID_STATE_ERROR 


Function: This finite-state machine is signalled if an MU_ID Registry exception prevents an MU_ID state 
from being set to TRANSFER_PENDING before the suffix is sent to the partner. The distribution is 
retained, and an exception-hold is placed on the next-DSU queues. DS_SEND_SYSTEM_ERROR 
is returned, which will eventually cause the conversation to be deallocated. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND BUILD SEND DMU” on page 163 
— START 


Signals from lower-level DS_Send finite-state machines: 


— from “DS SEND RETAIN DIST” on page 216 
DIST_RETAINED 
RELQ_ FAILED 
TERM_READ FAILED 
TERM_READ_RELQ FAILED 
HOLDQ_FAILED 
HOLDQ_RELQ FAILED 
HOLDQ _TERM_READ_FAILED 
HOLDQ TERM_READ_RELQ FAILED 


RELQ FAILED 

TERM READ FAILED 

TERM READ RELQ FAILED 
HOLDQ FAILED 

HOLDQ RELQ FAILED 

HOLDQ TERM READ FAILED 
HOLDQ TERM READ RELQ FAILED 


~~ 
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Signal DS_SEND_RETAIN_DIST with HOLDQ, specifying that an exception-hold is to be placed on the 
next-DSU queues. 


Notify operations of the exception condition. 
Signal caller with DS_ SEND _SYSTEM_ERROR. 
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DS_SEND_ SEND _DMU_NO MU _ID 


Function: This finite-state machine describes the functional processing for controlling the encoding and 


sending of a basic integrity DMU. States 3 and 4 represent a loop that repeatedly builds and 
sends parts of the distribution. States 4, 5 and 6 represent a loop that repeatedly reads from 
the server and builds and sends the server object. After the suffix has been sent successfully, 
the distribution is discarded (without confirmation of it being accepted by the partner). 
Exceptions are handled by “DS_SEND_EXCEPT_NO_MU_ID” on page 185. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS Send finite-state machines or procedures: 


— from “DS_SEND SEND DIST” on page 159 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_DISCARD_DIST” on page 218 
— DIST_DISCARDED 
— QUEUE FAILED 
— SERVER_FAILED 
— QUEUE AND_SERVER_FAILED 
— from “DS SEND _EXCEPT_NO MU_ID” on page 185 
— SEND_SIDE_EXCEPT 
— PROG_ERROR 
— PROTOCOL_ERROR 
— CONVERSATION_FAILURE 


¢ Signals from machines providing common services: 


— from “DS _SEND_SEND_CONVERSATION_MGR” on page 220 
— OK 
— PROG_ERROR 
— PROTOCOL_ERROR 
— CONVERSATION _FAILURE 
— from “IDLE_DETECTOR” on page 284 
— no signals returned from this FSM. 
— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— NO OBJECT_EXISTS 
— OBJECT_EOD 
— OBJECT_NOT_OK 


¢ from “BUILDER” on page 359: 


— BUILD OK 

— BUILD OK_GET_OBJECT 

— BUILD COMPLETE 

— BUILD COMPLETE_NO DATA 
— BUILD NOT_OK 
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Output 
Code 


Signal BUILDER with BUILD to start building the DTMU. 


Signal IDLE_DETECTOR with SOMETHING SENT. 
Signal DS_SEND_SEND_CONVERSATION_MGR with SEND_BUFFER to send the MU information to LU 
6.2. 


c Signal DS_SEND_EXCEPT_NO_MU_ID with ERROR_NO DATA SENT. 
Signal DS_SEND_EXCEPT_NO_MU_ID with PROG_ERR_RCVD. 
Signal DS_SEND_EXCEPT_NO_MU_ID with CONV_FAIL_RCVD. 


Signal DS_SEND_EXCEPT_NO_MU_ID with PROTO_ERR_RCVD. 


Signal DS_SEND_SEND_CONVERSATION_MGR with SEND BUFFER to send the MU information to LU 
6.2. 


Signal DS_SEND_CONVERSATION_CONTROL with DMU_SENT. 


Signal DS_SEND_DISCARD_DIST with START. 


Signal DS_SEND_EXCEPT_NO_MU_ID with SEND_SIDE_EXCEPT. 


Signal SERVER_MGR with READ to read the object and perform any initialization for reading, if not 
yet performed. 


Signal BUILDER with END_OBJECT to indicate that the server has returned EOD and the last 
segment of the object should be built, or if no object exists the length of the data will be 0. 

Signal caller with PROG_ERROR. 

Signal caller with CONVERSATION_FAILURE to indicate that an error has occurred in the conversa- 


tion between DS_Send and DS_Receive. 


Signal caller with PROTOCOL_ERROR. 
Signal caller with SEND_SIDE_EXCEPT. 


Signal caller with DISTRIBUTION COMPLETE to indicate that the MU has been encoded and sent to 
DS Receive. 
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DS SEND _EXCEPT_NO MU _ID 


Function: 


This finite-state machine describes the functional processing for errors detected while a basic- 
integrity DMU is being transferred to the partner DSU. Depending on the exception, the distrib- 
ution is either discarded or retained to be retried (without mid-MU restart) later. The next-DSU 
queues are held, if appropriate. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS _SEND_SEND_DMU_NO_MU_ID” on page 181 
— SEND_SIDE_EXCEPT 
— ERROR_NO_DATA_SENT 
— CONV_FAIL_RCVD 
— PROG_ERR_RCVD 
— PROTO_ERR_RCVD 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS SEND DISCARD_DIST” on page 218 
— DIST DISCARDED 
— QUEUE FAILED 
— SERVER_FAILED 
— QUEUE AND SERVER_FAILED 
— from “DS SEND RETAIN DIST” on page 216 
— DIST_RETAINED 
— RELQ FAILED 
— TERM_READ FAILED 
— TERM READ RELQ FAILED 
— HOLDQ_FAILED 
— HOLDQ_RELQ_FAILED 
— HOLDQ TERM_READ_FAILED 
— HOLDQ TERM_READ_RELQ_ FAILED 


¢ Signals from machines providing common services: 


— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITHOUT_MID_MU 
— RETRIABLE_RETRY_EXHAUSTED 
— from “QUEUE_MGR” on page 357 
— QUEUE _OK 
— QUEUE_NOT_OK 


¢ Signals from LU 6.2 presentation services 


~ OK 

— ALLOCATION ERROR 
— DEALLOCATE_ABEND 
— PROG_ERROR 

— SVC_ERROR 

— RESOURCE_FAILURE 
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Signal LU 6.2 presentation services with SEND_ERROR. 
Signal UPM_EXCEPT_RECOVERY_ACTION with the exception code. 


: 
Em 
je [signa caller with SEND_SIDE EXCEPT. —SSCSCSC~“~S~“~S~S~S~S 
a | sgnar caer wih PROG._ERROR,——SSCSC~“~S*S*~“~*~“~S~“~S~S~S 
In| lana caer with ROTOCOLERROR—SOSC~“~*~“~*~*~“~S~S~S~S~S 


Signal QUEVE_MGR with HOLD to set an exception-hold for all next-DSU queues for this connection. 
No distributions will sent to the partner DSU until the cause of the exception is corrected. The 
control MU queue is not held. 
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DS_SEND_SEND_CONTROL_MU 


This finite-state machine describes the functional processing for sending a single control MU 
(PRMU, SEMU or CQMU). This routine reads the next CMU from the control MU queue, sends 
it, and discards it. If an exception occurs, the MU is not discarded, but is left on the queue to — 
be resent later. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_SENDING” on page 156 
— SEND 


¢ Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE OK 
— QUEUE NOT_OK 
— QUEUE EMPTY 
— from “IDLE_DETECTOR” on page 284 
— No signals are returned from this FSM. 
— from “DS_SEND_SEND_CONVERSATION_MGR” on page 220 
— OK | 
— CONVERSATION_FAILURE 
— PROG_ERROR 
— PROTOCOL_ERROR 


RESET | CMU | 
po | oz | os 
2a / 


RET RET RET 
RET | CONV | PROG | SYS | PROT | CONV 
SENT | FAIL ERR ERR ERR FAIL 
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Output 
Code 
Signal QUEUE_MGR with READQ specifying queue(CONTROL_MU_QUEUE). 


Signal IDLE_DETECTOR with SOMETHING SENT. 
Signal DS_SEND_SEND_CONVERSATION_MGR with SEND_BUFFER to send the control MU to the 
partner DSU. 


Notify operations of the exception condition. No DRMU will be generated because no distribution 
was involved. 

Signal QUEUE_MGR with HOLD to place an exception-hold on all next-DSU queues and also on the 
control MU queue for this connection. No more MUs will be sent to the partner DSU. 


fd «| Signal caller with CONTROL_MU_QUEUE_EMPTY. 
fe «| Signal QUEUE_MGR with DEQ, discarding the contro! MU. 
ie. = QUEVUE_MGR with RELEASEQ, freeing the control MU for resending later. 


Notify operations of the exception condition. 
Signal caller with PROTOCOL_ERROR. 
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DS_SEND_RECEIVING 


Function: This finite-state machine receives control MUs from the partner DSU. The FSM loops, receiving 
a CRMU or a REMU from the partner, parsing it and signalling the appropriate handler. The 
CRMU’s terminate_conversation bit is also passed to DS_SEND_CONVERSATION_CONTROL. 
The FSM returns to the caller upon entering the LU 6.2 send state, detecting a conversation 
failure or deallocation, or encountering a violation of the DS usage of the LU 6.2 verbs. A 
PROG_ERROR indication (indicating that the partner issued a Send_Error verb) leaves the partner 
in send state and is simply ignored. 


This FSM gets control from one of the following: 
* Signals from higher-level DS Send finite-state machines or procedures: 


— from “DS_SEND_ MANAGER” on page 154 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_REMU_HANDLER” on page 204 
— REMU_OK 
— DS_SEND_SYSTEM_ERROR 
— from “DS_SEND_CRMU_HANDLER” on page 192 
— CRMU_OK 
— DS _SEND_SYSTEM_ERROR 
— from “DS SEND _CONVERSATION_ CONTROL” on page 222 
— no signals are received from this FSM 


¢ Signals from “PARSER” on page 359: 


— REMU 
— CRMU 
— PARSE_NOT_OK 


¢ Signals from machines providing common services: 


— from “RCV_BUFFER_MGR” on page 282 
— OK 
— CONVERSATION_FAILURE 
— CHANGE_DIRECTION 
— PROG_ERROR 
— PROTOCOL_ERROR 
— DEALLOCATE_ NORMAL 
— from “IDLE DETECTOR” on page 284 
— no signals are received from this FSM 
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Signal DS_SEND_CONVERSATION CONTROL with RECEIVING. 
Signal RCV_BUFFER_MGR with RECEIVE BUFFER. 

lb «| Signal PARSER with PARSE. 

lc =| Signal caller with DEALLOCATE_LOCAL. 

Signal caller with CHANGE DIRECTION. 

Notify operations of the exception condition. 

Signai caller with DEALLOCATE_ABEND. 


Signal IDLE_DETECTOR with SOMETHING_RECEIVED. 
Signal DS_SEND CONVERSATION CONTROL with the terminate_conversation flag from the CRMU. 
Signal DS_SEND_CRMU_HANDLER with START. 


Signal IDLE_DETECTOR with SOMETHING_RECEIVED. 
Signal DS_SEND_REMU_HANDLER with START. 
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DS_SEND_CRMU_HANDLER 


Function: 


This finite-state machine processes a CRMU’s MU_ID state indication, which may be ComPLETE, 
IN_TRANSIT, NOT_RECEIVED, TERMINATED, SUSPENDED, Or PURGED. 


In states 1-3, the FSM finds the specified distribution on the next-DSU queue, or discovers that 
the specified distribution does not exist. The queue hold indication may be ignored for this 
operation, since the hold is intended to prevent distributions from being sent, not to prevent 
CMU processing. CRMUs without MU_/Ds are simply logged; those with old instance numbers 
are discarded. 


In states 4-11, the specific actions taken for a given distribution and CRMU depend on the 
MU_ID state, whether the distribution can be retried (with a new MU_/D or with a DCMU), and 
the partner’s state. The actions include purging the distribution because the partner has 
accepted responsibility, marking the distribution to be restarted later using a DCMU, purging 


the MU_ID and retrying later with a new MU_ID, and terminating the distribution. If the speci- 


fied distribution does not exist and DS_Send’s MU_ID state is PURGED, a PRMU is generated; if 
DS_Send’s MU_ID state is NOT_ASSIGNED, the CRMU’s MU_ID state is examined to determine if 
an MU sequence error has been detected. If so, an exception-hold is placed on the next-DSU 
queues. 


Receiving a CRMU(IN_TRANSIT) may indicate a hung conversation, and should be reported to 
operations. At other times, the CRMU(IN_TRANSIT) probably indicates a race condition in which a 
SEMU was received before its accompanying Send_Error. In the latter cases, a CQMU is 
issued to solicit a CRMU(TERMINATED) or CRMU(SUSPENDED). 


A CRMU(NOT_RECEIVED) may also indicate a hung conversation, or it may indicate a lost SEMU 
or DMU. A SEMU is perceived to be lost when an MU_/D with an MU_ID state of 
TERMINATION_PENDING Or RETRY_PENDING is reported by the partner as NOT_RECEIVED; such a SEMU is 
simply reissued. A DMU is perceived to be lost when an MU_/D with an MU_ID state of 
CQMU_PENDING Or TRANSFER_PENDING is reported by the partner as NOT_RECEIVED. Lost DMUs are 
handled by issuing a SEMU; the partner will respond to the SEMU with a CRMU(TERMINATED), 
which, in turn, solicits a PRMU. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS SEND RECEIVING” on page 190 
— START 
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¢ Signals from lower-level DS_Send finite-state machines or procedures: 


— from “DS _SEND_MU_ID_REGISTRY” on page 223 
— NOT_ASSIGNED 
— TRANSF_PEND 
— CQMU_PEND 
— TERM_PEND 
— RETRY_PEND 
— SUSPENDED 
— INSTANCE NUM_OK 
— INSTANCE _NUM_NOT_OK 
— MU_ID_OP_NOT_OK 

— from “DS_SEND_RELEASE ON CRMU” on page 196 
— CMU_OK 
— DS_SEND_SYSTEM_ERROR 

— from “DS SEND _PURGE_ON_CRMU” on page 198 
— CMU_OK 
— DS_SEND_SYSTEM_ERROR 

— from “DS_SEND_RETRY_ON CRMU” on page 200 
— CMU_OK 
— DS SEND SYSTEM _ERROR 

— from “DS_SEND_TERMINATE_DIST” on page 214 
— CMU_OK 
— DS_SEND_SYSTEM_ERROR 

— from “DS_SEND_ISSUE_SEMU_ON_CRMU” on page 202 
— CMU_OK 
— DS SEND SYSTEM_ERROR 


Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE_OK 
— QUEUE_ENTRY_IN_USE 
— QUEUE_EMPTY 
— QUEUE _NOT_OK 
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Output 
Code 


Signal QUEVUE_MGR with READ® specifying queue(NEXT-DSU-QUEUE) to get the distribution specified by 
the CRMU. The hold flag may be ignored for this operation. If no MU_ID is specified in the CRMU, 

the CRMU is logged, reported to the operator, and processing continues as if QUEUE_MANAGER had 
returned QUEUVE_ENTRY_IN_USE. 


Signal DS_SEND_MU_ID_REGISTRY with INSTANCE NUMBER to compare the CRMU’s instance 


number with the current MU_ID registry instance number. \f they do not match, then 
INSTANCE_NUM_NOT_OK is returned. 


Signal caller with CRMU_OK. 


Interrogate the MU_ID state of the CRMU. 


Notify operations of the exception condition. 
Signal caller with CRMU_OK. 


Signal DS_SEND_MU_ID_REGISTRY with INSPECT. 


Signal DS_SEND_ RELEASE ON CRMU with NO_ACTION. 


Signal DS_SEND_RELEASE_ON_CRMU with NO_ACTION. Implementations may chose to notify oper- 
ations that a hung conversation may exist. 


Signal DS_SEND_RETRY_ON_CRMU with RETRY. 
Signal DS_SEND_RETRY_ON_CRMU with RETRY_NO_MID_MU. 
k Signal DS_SEND_PURGE_ON_CRMU with DISCARD_AND_ PURGE. 


Signal DS_SEND_ISSUE_SEMU_ON_CRMU with START. 


Signal DS_SEND_RELEASE_ON_CRMU with QUERY. This output code is usually used to handle a 
race condition in which a SEMU has outrun a Send_Error. However, in some circumstances, a hung 
conversation may exist, and implementations may notify the operator. 


Signal DS_SEND_TERMINATE_DIST with REPORT_AND_ PURGE. 
Signal DS_SEND_PURGE_ON_CRMU with PURGE. 
Signal caller with DS_SEND_SYSTEM_ERROR. 


An MU sequence error has been detected. Signal QUEUE_MGR with HOLD to place an exception- 
hold on all next-DSU queues. 


Signal DS_SEND_RELEASE_ON_CRMU with MU_ID_EXCEPT. 
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DS _SEND_RELEASE_ON_CRMU 


This finite-state machine is signalled when no processing is to be performed on the distribution 
or MU_ID. It is signalled in the following cases: 


The CRMU’s instance number is low, and the CRMU is to be discarded. 

An MU_ID Registry exception has occurred. 

The partner DSU is perceived to be impatient, and has sent a CRMU(NOT_RECEIVED) for an 
MU_ID that is either NOT_ASSIGNED or IN_TRANSIT. 

The partner DSU is perceived to be impatient, and reports an MU_/D as IN_TRANSIT when 
DS_ Send expects some other active state. 


A CQMU is issued, if requested. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_CRMU_HANDLER” on page 192 
— QUERY 
— NO ACTION 
— MU_ID EXCEPT 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE OK 
— QUEUE NOT_OK 
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Build the CQMU and signal QUEUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to deter- 
mine the restart position. 


Notify operations of the exception condition. 
Signal QUEUE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 
queue. Following the RELEASEQ, the entry will be available for processing. 


Signal caller with DS SEND _SYSTEM_ERROR. 
Signal caller with CMU_OK. 


Notify operations of the exception condition. 
Signal caller with CMU_OK. 
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DS_SEND_PURGE_ON_CRMU 


This finite-state machine changes the MU_ID state to PURGED, and issues a PRMU to notify the 
partner that the MU_/D has been purged. It optionally discards the distribution. This FSM is 
called whenever the partner has taken responsibility for the distribution by issuing a 
CRMU(compPLEtTE), or when the partner reports as active an MU_/D that DS_Send has purged. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_CRMU_HANDLER” on page 192 
— PURGE 
— DISCARD_AND_PURGE 


° Signals from lower-level DS_Send finite-state machines or procedures: 


— from “DS _SEND_DISCARD_DIST” on page 218 
— DIST_DISCARDED 
— QUEUE _FAILED 
— SERVER_FAILED 
— QUEUVE_AND_SERVER_FAILED 
— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE _OK 
— QUEUE _NOT_OK 


DISC PURGE 
RESET DISC DIST MU_ID 


Cn 
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Signal DS_SEND_MU_ID_REGISTRY with PURGE. If the MU_/D has already been purged, 


DS_SEND MU_ID_REGISTRY returns MU_ID_OP_OK. 


Signal caller with CMU_OK 


Signal DS_SEND_DISCARD_DIST with START 


Build the PRMU and signal QUEVUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to purge 
the partner’s knowledge of the MU_/D. 

Notify operations of the exception condition. 

Signal caller with CMU_OK 


Signal caller with DS_SEND_SYSTEM_ERROR 
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DS_SEND_RETRY_ON CRMU 


Function: If a distribution’s transfer to the partner is interrupted by an exception, DS_Send determines 
whether to terminate the distribution or to attempt to recover from the exception. If DS Send 
decides to recover, this FSM is called. It either suspends the distribution by setting the MU_/D 
State to SUSPENDED, or it purges the MU_/D and prepares the distribution to be retried later with 
a new MU_ID. 


Suspending the distribution merely involves setting the MU_/D state to SUSPENDED, recording the 
appropriate restart position for the DCMU, and issuing a RELEASEQ signal to the queue 
manager. Depending on implementation-defined circumstances (e.g., the exception may have 
been caused by an operator suspending this transmission), implementations may put special 
hold conditions on the distribution. 


Purging the MU_ID involves setting the MU_/D state to PURGED and issuing a PRMU to inform 
the partner. Preparing the distribution to be retried with a new MU_/D involves terminating the 
-server’s restartability (if appropriate), and issuing the RELEASEQ signal to the queue manager. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_CRMU_HANDLER” on page 192 
— RETRY 
— RETRY_NO_MID_MU 


¢ Signals from lower-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 
— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_WITHOUT_MID_MU 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE_OK 
— QUEUE _NOT_OK 

— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
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Signal SERVER_MGR with TERMINATE_RESTARTABILITY. 
Signal DS_SEND_MU_ID_REGISTRY with SUSPENDED. 


Notify operations of the exception condition. 
Signal QUEUE_MGR with RELEASEOQ to remove the in-use mark from the entry on the next-DSU 
queue. Depending on the circumstances surrounding the distribution’s continuation (for example, 

the distribution’s transfer may have been suspended by an operator), implementations may mark the 
distribution with an operator-hold. An operator-hold must be explicitly released by the operator 
before it can be continued. If no operator-hold is placed on the distribution, then following the 
RELEASEQ it will be available for processing. 


Signal DS_SEND_MU_ID_REGISTRY with PURGE. 


Build the PRMU and signal QUEUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to purge 


the MU_/D value in the partner DSU. 
Notify operations of the exception condition. 
Signal caller with CMU_ OK. 

h Notify operations of the exception condition. 
Signal caller with DS_SEND_ SYSTEM ERROR. 
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DS_SEND_ISSUE_SEMU_ON_CRMU 


This finite-state machine issues a SEMU and releases the distribution for later processing. The 
SEMU may have been lost (or at least appears to have been lost), or may be issued to termi- 
nate an apparently lost distribution. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_ Send finite-state machines or procedures: 


— from “DS_SEND_CRMU_HANDLER” on page 192 
— START 


¢ Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE_OK 
— QUEUE NOT_OK 


If a SEMU has been previously issued for this distribution, then rebuild an exact copy of the original 
SEMU and signal QUEUVE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to send it. Ifa 
SEMU has not been issued previously, or no such distribution exists, then build a SEMU using SNA 
Report Code “System Exception--Identifiable” and signal QUEVE_MGR with WRITEQ specifying 
queue(CONTROL_MU_QUEUE) to send it. 


Notify operations of the exception condition. 
Signal QUEVE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 
queue. Following the RELEASEQ, the entry will be available for processing. 


Signal caller with DS_SEND_SYSTEM_ERROR. | 
Signal caller with CMU_OK. 


Notify operations of the exception condition. 
Signal caller with CMU_OK. 
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DS_SEND_REMU_HANDLER 


Function: This finite-state machine handles REMUs. In states 1-3, the FSM finds the specified distribution 
on the next-DSU queue. The queue hold indication is ignored for this operation, since the hold 
is intended to prevent more distributions from being sent, not to prevent control processing of 
distributions with active MU_ID states. If no MU_ID is specified, the REMU is logged, but no 
other action is taken. If the specified distribution does not exist and the MU_ID state is PURGED, 
the REMU is discarded; if the MU_/D state is NOT_ASSIGNED, the partner has committed an MU 
sequence error, and an exception-hold is placed on the next-DSU queues. If the instance 
number given in the REMU does not match that in the distribution, the REMU is discarded. 
REMUs reporting already-detected conversation failures are discarded, since the recovery 
processing for these failures has already been initiated by a SEMU. 


In states 4-10, the specific actions taken for a given distribution and REMU depend on the 
MU_ID state, the ability of the DSU to retry the distribution with a new MU_/D or restart it with 
a DCMU, and the REMU’s exception condition. The actions include querying the partner to 
determine the restart position, purging the MU_ID and retrying the distribution with a new 
MU_ID at a later time, and terminating the distribution. Retriable exceptions always result in 
the next-DSU queues being held. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_RECEIVING” on page 190 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— TRANSF_PEND 
— CQMU_PEND 
— TERM_PEND 
— RETRY_PEND 
— INSTANCE_NUM_OK 
— INSTANCE_NUM_NOT_OK 
— MU_ID_OP_NOT_OK 
— from “DS_SEND_QUERY_ON_REMU” on page 208 
— CMU_OK 
— DS_SEND_SYSTEM_ERROR 
— from “DS_SEND_RETRY_ON_REMU” on page 210 
— CMU_OK 
— DS_SEND_SYSTEM_ERROR 
— from “DS_SEND_TERMINATE_DIST” 90n page 214 
— CMU_OK 
— DS SEND _SYSTEM_ERROR 
— from “DS_SEND_CHECK_CONV_FAIL” on page 212 
— NOT_RETRIABLE 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_WITHOUT_MID_MU 
— RETRIABLE_RETRY_EXHAUSTED 
— DUP_CONV_FAIL_REPORT 
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* Signals from machines providing common services: 


— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_ WITHOUT_MID_MU 
— RETRIABLE_RETRY_EXHAUSTED 
— from “QUEUE MGR” on page 357 
— QUEUE OK 
— QUEUE_EMPTY 
— QUEUE ENTRY_IN USE 
— QUEUVE_NOT_OK 
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Output 
Code 


Signal QUEUE_MANAGER with READQ specifying queuve(NEXT-DSU-QUEUE) to get the distribution speci- 
fied in the REMU. The HOLD indication is ignored for this operation. !f no MU_/D is specified in the 
REMU, the REMU is logged, reported to the operator, and processing continues as if 

QUEUE_MANAGER had returned QUEUE_EMPTY and the MU_/D state was PURGED. 


Signal DS_SEND_MU_ID_REGISTRY with INSTANCE_NUMBER to compare the REMU’s /nstance 


number with the the current MU_ID registry instance number. \|f they do not match, then 
INSTANCE_NUM_NOT_OK is returned. 


Signal caller with REMU_OK. 


Signal QUEVUE_MANAGER with READO specifying queuve(NEXT-DSU-QUEUE) suspend to get the distrib- 
ution. Implementations may set a timer to avoid suspending for too long. If the timer expires before 
the distribution is available, the operator is notified that a potential hung session exists, and proc- 
essing continues as though QUEUE_EMPTY had been returned and the MU_/D state were PURGED. 
Implementations unable to suspend for the READQ@ may set a timer and retry the READQ when the 
timer expires. If this subsequent READQ fails, the operator is notified and processing continues as 
though QUEUE_EMPTY had been returned and the MU_ID state were PURGED. 


Signal DS_SEND_MU_ID_REGISTRY with INSPECT. 


Signal QUEVE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 


queue. Following the RELEASEQ, the entry will be available for processing. 


An MU sequence error has been detected. Signal QUEUE_MGR with HOLD to hold all next-DSU 
queues. 


Notify operations of the exception condition. 
Signal caller with REMU_OK. 
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DS_SEND_QUERY_ON_REMU 


Function: This finite-state machine retains the distribution (i.e., Terminate_Read server verbs and the 
RELEASEQ queue operation are performed), holds the next-DSU queues with an exception-hold, 
sets the MU_ID state to CQMU_PENDING, and issues a CQMU to query the partner. This FSM is 
signalled when a REMU reporting a retriable exception is received, mid-MU restart is possible, 
and the sender’s MU_/D state is TRANSFER_PENDING Or RETRY_PENDING. 


Failures involving the MU_ID registry or the control MU queue cause 
DS_SEND_SYSTEM_ERROR to be returned. Otherwise, CMU_OK is returned. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_REMU_HANDLER” on page 204 
— START 


¢ Signals from lower-level DS_ Send finite-state machines: 


— from “DS_SEND_RETAIN_DIST” on page 216 
— DIST_RETAINED 
— RELQ FAILED 
— TERM_READ_FAILED 
— TERM_READ_RELQ_FAILED 
— HOLDQ_FAILED 
— HOLDQ_RELQ_ FAILED 
— HOLDQ_TERM_READ_FAILED 
— HOLDQ_TERM_READ_RELQ_FAILED 
— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE _OK 
— QUEVE_NOT_OK 
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QUEUE NOT OK 


Signal DS_SEND_RETAIN_DIST with HOLDO. 


Signal DS_SEND_MU_ID_REGISTRY with CQMU_PENDING to set the MU_ID state. 


Build the CQMU and signal QUEVE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to deter- 
mine the restart position. If the sender had detected an exception previously and issued a SEMU, 
implementations may choose to suppress this CQMU, since the SEMU will solicit a CRMU. In such 
cases, processing continues as though QUEUE_OK had been returned. | 


Notify operations of the exception condition. 
Signal caller with CMU_OK. 

Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 


7 
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DS_SEND_RETRY_ON_REMU 


Function: This FSM prepares a distribution for retry with a new MU_ID. The (existing) MU_/D is purged 
from the registry, a PRMU is sent, the next-DSU queues are held with an exception-hold, and 
the MU_ID state is changed to NOT_ASSIGNED. A subsequent invocation of DS_Send will assign a 
new MU_ID to this distribution and resend it. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS Send finite-state machines or procedures: 


— from “DS_SEND_REMU_HANDLER” on page 204 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS _SEND_RETAIN_DIST” on page 216 
— DIST_RETAINED 
— RELQ FAILED 
— TERM_READ_FAILED 
— TERM_READ_RELQ FAILED 
— HOLDQ_FAILED 
— HOLDQ_RELQ_FAILED 
— HOLDQ TERM_READ_FAILED 
— HOLDQ_TERM_READ_RELQ_FAILED 
— from “DS_SEND_MU_ID_REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE_OK 
— QUEUE_NOT_OK 

— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
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QUEUE NOT OK 


Signal DS_SEND_MU_!ID_REGISTRY with PURGE. 
Signal SERVER_MGR with TERMINATE_RESTARTABILITY, if applicable. 


Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 


ld | Signal DS_SEND_RETAIN_DIST with HOLDQ. 


Build the PRMU and signal QUEVE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to purge 
the partner’s knowledge of the MU_/D. 

Notify operations of the exception condition. 

Signal caller with CMU_OK. 
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DS_SEND_CHECK_CONV FAIL 


This finite-state machine determines if the just-received REMU is reporting an already-detected 
conversation failure. If so, the REMU will be discarded. If not, this routine returns the appro- 
priate retry action. This FSM is signalled whenever a REMU is received for an MU_ID state of 
TERMINATION_PENDING OF RETRY_PENDING. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_REMU_HANDLER” on page 204. 
— START 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “UPM_CHECK_DUP_CONV_FAIL_REPORT” on page 224 
— DUP_CONV_FAIL_REPORT 
— NOT _DUP_CONV_FAIL_REPORT 


¢ Signals from machines providing common services: 


— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_WITHOUT_MID_MU 
— RETRIABLE_RETRY_EXHAUSTED 
— from “QUEUE_MGR” on page 357 
— QUEUE_OK 
— QUEUE _NOT_OK 


— 


= 


RETRIABLE RETRY EXHAUSTED 
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Output 
Code 


Signal UPM_CHECK_DUP_CONV_FAIL_REPORT with START. If DS_ Send detected a conversation 
failure on this distribution and sent a SEMU reporting conversation failure, and if the just-received 
REMU reports conversation failure, then the UPM returns DUP_CONV_FAIL_REPORT. Otherwise, 

NOT_DUP_CONV_FAIL_REPORT is returned. 


Signal QUEUE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 
queue. Following the RELEASEQ, the entry will be available for processing. 


Signal UPM_EXCEPT_RECOVERY_ACTION with the relevant fields from the REMU. 


Signal caller with DUP_CONV_FAIL_REPORT. 
Signal caller with NOT_RETRIABLE. 


Signal caller with RETRIABLE_WITH_MID_MU. 
Signal caller with RETRIABLE_WITHOUT_MID_MU. 


Signal caller with RETRIABLE_RETRY_EXHAUSTED. 


a me 
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DS_SEND_TERMINATE_DIST 


Function: This finite-state machine is called when a REMU or CRMU is received and DS_Send determines 


that an exception condition makes reattempting transmission of the distribution inappropriate. 
Terminating a distribution involves 


¢ Holding the next-DSU queues (if requested to do so). 
¢ Generating a distribution report (if appropriate). 
° Setting the MU_/D state to PURGED. 
¢ Signalling DS_SEND_DISCARD_DIST to 
— Remove the distribution from the next-DSU queue and discard it. 
Terminate the server’s restartability for the server object (if appropriate). 


Decrement the server’s DS lock count for the server object (if appropriate). 
¢ generating a PRMU to the partner. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_REMU_HANDLER” on page 204 
— HOLD_AND_REPORT_AND_ PURGE 
— REPORT_AND_ PURGE 

— from “DS _SEND_CRMU_HANDLER” on page 192 
— REPORT_AND_PURGE 


¢ Signals from lower-level DS_Send finite-state machines: 


— from “DS SEND DISCARD_DIST” on page 218 
— DIST DISCARDED 
— QUEUE_FAILED 
— SERVER_ FAILED 
— QUEUE_AND_SERVER_FAILED 

— from “DS SEND _MU_ID REGISTRY” on page 223 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE_OK 
— QUEUE NOT_OK 
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Signal QUEVE_MGR with HOLD specifying an exception-hold for all next-DSU queues for this con- 
nection. No distributions should be sent to the partner DSU until the cause of the exception is cor- 
rected. The control MU queue is not held. 


Generate the distribution report, if appropriate, and signal QUEUE_MGR with WRITEOQ specifying 
queue(ROUTER_DIRECTOR_QUEUE). If a report is not appropriate, QUEUE_MGR returns QUEVE_OK. 


Signal DS_SEND_MU_ID_REGISTRY with PURGE. | 
Signal DS_SEND_DISCARD_DIST with START. 


Notify operations of the exception condition. 
Signal caller with DS_SEND_SYSTEM_ERROR. 


Build the PRMU and signal QUEVE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE) to purge 
the partner’s knowledge of the MU_ID. 


Notify operations of the exception condition. 
Signal caller with CMU_OK. | 
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DS_SEND_RETAIN_DIST 


Function: When processing on a distribution is halted temporarily, this FSM is signalled to terminate any 
server operations in progress and to clear the distribution’s in-use mark, making the distrib- 
ution available for further processing. Retaining a distribution involves the following actions: 


¢ The next-DSU queues are held with an exception-hold, if requested. 

¢ A Terminate_Read verb is issued to the server, but the restartability of the server (if ori- 
ginally requested) is maintained. 

¢ A RELEASEOQ signal is sent to queue manager to remove the in-use mark from the distrib- 
ution. The distribution will then be available to other DS_Send processes. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_CLEANUP_DMU” on page 166. 
— NO_HOLDOQ 
— from “DS_SEND_CLEANUP_EXCEPT” on page 172. 
— HOLDQ 
— NO_HOLDOQ 
— from “DS_SEND_PROG_ERROR_RECEIVED” on page 174. 
— NO_HOLDQ 
— from “DS_SEND_DMU_PROTOCOL_ERROR” on page 176. 
— HOLDQ 
— from “DS _SEND_EXCEPT_NO_MU_ID” on page 185. 
— HOLDQ 
— from “DS_SEND_QUERY_ON_REMU” on page 208. 
— HOLDQ 
— from “DS_SEND_RETRY_ON_REMU” on page 210. 
— HOLDQ 
— NO_HOLDQ 


¢ Signals from machines providing common services: 


— from “QUEUE _MGR” on page 357 
— QUEUE_OK 
— QUEUE _NOT_OK 

— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
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Signal QUEVE_MGR with HOLD specifying an exception-hold on all next-DSU queues for this con- 
nection; no more distributions should be sent to the partner DSU. The control MU queue is not held. 


Signal SERVER_MGR with TERMINATE_READ specifying SUSPEND. If no Initiate_Read has opened the 
server object or no server object exists for this distribution, SERVER_MGR returns OBJECT_OK. 


Signal QUEVE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 
queue. Following the RELEASEQ, the entry will be available for processing. 


Signal caller with DIST_RETAINED. 


Notify operations of the exception condition. 
Signal caller with RELQ_FAILED. 


Notify operations of the exception condition. 
Signal caller with TERM_READ_FAILED. 

Notify operations of the exception condition. 
Signal caller with TERM _READ_RELQ_ FAILED. 
Notify operations of the exception condition. 
Signal caller with HOLDQ_FAILED. 

Notify operations of the exception condition. 
Signal caller with HOLDQ_RELQ_FAILED. 

Notify operations of the exception condition. 
Signal caller with HOLDQ_TERM_READ_ FAILED. 


Notify operations of the exception condition. 
Signal caller with HOLDQ_TERM_READ_RELQ_ FAILED. 
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DS_SEND_DISCARD_DIST 


Function: This finite-state machine describes the functional processing for deleting a distribution from the 


DSU. This involves the following actions: 


e If a server object exists for this distribution, it is deleted. This may involve: 
— A Terminate_Read or Terminate_Restartability server verb is issued, if appropriate. 
— The DS lock count for the server object is decremented by the server manager, and the 


server object may be deleted from non-volatile storage if both the agent and DS lock 
counts are 0. 


¢ The queue manager is signalled with DEQ to remove the distribution from the next-DSU 
queue. 
This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 
— from “DS SEND _SEND_DMU_NO_MU_ID” on page 181 
— START 


— from “DS SEND EXCEPT_NO_MU_ID” on page 185 
— START 


— from “DS_SEND_PURGE_ON_CRMU” on page 198 
— START 


— from “DS SEND _TERMINATE_DIST” on page 214 
— START 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE OK 
— QUEUE _NOT_OK 

— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
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If appropriate, signal SERVER_MGR with TERMINATE_READ terminating restartability of the server 


If a Terminate_Read specifying SUSPEND has been issued previously, then signal SERVER_MGR with 


TERMINATE_RESTARTABILITY, if appropriate. 
If no Initiate_ Read has opened the server object or no server object exists for this distribution, 


SERVER_MGR returns OBJECT_OK. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count on the server 
object. If no server object exists, OBJECT_OK is returned. 


a Signal QUEVE_MGR with DEQ to remove the distribution from the next-DSU queue. 


Signal caller with DIST_DISCARDED. 

Notify operations of the exception condition. 
Signal caller with QUEVUE_FAILED. 

Notify operations of the exception condition. 
Signal caller with SERVER_FAILED. 

Notify operations of the exception condition. 
Signal caller with QUEVE_AND_SERVER_FAILED. 
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DS_SEND_SEND_CONVERSATION_MGR 


Function: This finite-state machine describes the functional processing for sending a buffer to LU 6.2 
presentation services using the the Send_Data verb. 


This FSM gets control from one of the following: 
¢ Signals from higher-level finite-state machines: 


— from “DS_SEND_BUILD_SEND_DMU” on page 163 
— SEND_BUFFER 

— from “DS_SEND_SEND_DMU_NO_MU_ID” on page 181 
— SEND BUFFER 

— from “DS _SEND_SEND_CONTROL_MU” on page 188 
— SEND BUFFER 


Signals from lower-level finite-state machines: 


— from “DS_SEND_CONVERSATION_CONTROL” on page 222 
— no signals received from this FSM. 


Signals from LU 6.2 presentation services: 


ALLOCATION_ERROR 
DEALLOCATE_ABEND 
PROG_ERROR 
SVC_ERROR 
RESOURCE_FAILURE 
OK 


ALLOCATION ERROR 
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Signal LU 6.2 presentation services with Send_Data to send the encoded information to the partner 
DSU 


Signal caller with OK to indicate that the LU 6.2 request was completed successfully. 

Signal caller with CONVERSATION_FAILURE to indicate that some error has occurred on the conver- 
sation between DS_Send and DS_Receive. 

Signal caller with PROG_ERROR to indicate that the partner DSU has signalled that an error has 
occurred. | 


Signal caller with PROTOCOL_ERROR to indicate a violation of DS use of the LU 6.2 basic conversa- 
tion verbs has occurred between DS_Send and DS_Receive. 
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DS_SEND_CONVERSATION_CONTROL 


This finite-state machine remembers if DS_Send is allowed to send a distribution, send only 
control MUs, or must terminate the conversation. OPERATOR_QUIESCE_CONVERSATION 
shows the actions for handling an operator command to prevent further distribution traffic over 
the conversation. After any waiting CMUs have been exchanged, the conversation will be deal- 
located. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Send finite-state machines or procedures: 


— from “DS_SEND_SENDING” on page 156 
— QUERY_FLOW_CONTROL 
from the Operator 
— OPERATOR_QUIESCE_CONVERSATION 
from “DS_SEND_CLEANUP_DMU” on page 166 
— DMU_SENT 
from “DS _SEND_SEND_DMU_NO_MU_ID” on page 181 
— DMU_SENT 
from “DS_SEND_RECEIVING” on page 190 
— RECEIVING 
— CRMU(TERM_CONVERSATION bit) 


QUERY FLOW CONTROL 
RECEIVING 


OPERATOR QUIESCE CONVERSATION | 


CRMU(TERM CONV= YES) 
CRMU(TERM CONV=NO) 
DMU SENT 


Signal caller with SEND_DISTRIBUTION. 
Signal caller with SEND_CONTROL_MU. 


Signal caller with TERMINATE_CONVERSATION. 
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DS_SEND_MU_ID_REGISTRY 
This FSM manages DS_Send’s MU _ID registry for a single connection. Its 
inputs and actions are listed below. All inputs except INSPECT and 
INSTANCE_NUMBER return either MU_ID_OP_OK or MU_ID_ OP _NOT_OK. 


Assign 


Allocates an entry in the MU_ID registry and assigns to it the next available 
MU_!ID value, enters the distribution location information, sets the MU_/D 
State to IN_TRANSIT and sets the instance number to ONE (1). The MU_ID field 
in the appropriate next-DSU queue entry is also updated. 


Suspend 

Sets the MU_ID state to be SUSPENDED. 

CQMU_ Pending 

Sets the MU_ID state to be CQMU_PENDING. 

In_ Transit 

Sets the MU_/D state to be IN_TRANSIT and increments the instance number. 
Inspect 


Returns the designated MU_/D state (NOT_ASSIGNED, IN_TRANSIT, 
TRANSFER_PENDING, CQMU_PENDING, RETRY_PENDING, TERMINATION PENDING, SUS- 
PENDED Or PURGED) or, if the MU_ID registry is inaccessible, 

MU_ID OP_NOT_OK. MU_IDs less than the smallest MU_/ID contained in 
the registry return PURGED. MU_!IDs greater than the highest MU_ID con- 
tained in the registry return NOT_ASSIGNED. 


Purge 


Sets the MU_ID state to be PURGED and removes the MU_ID entry’s distrib- 
ution location information. Also, the MU_/D field in the appropriate 
next-DSU queue entry is set to null. Note that setting an MU_ID state to 
PURGED signifies only the breaking of the MU_/D-to-distribution association; 
nothing is implied about the fate of the distribution. The distribution may be 
retried with a different MU_/D, or the operator may reroute it, or the DSU 
may terminate it and issue a distribution report (if appropriate), or the DSU 
may simply discard it because the partner has accepted responsibility. 


Entries containing the MU_ID state PURGED may be aged out of the registry. 
Retry_Pending 

Sets the MU_ID state to be RETRY_PENDING. 

Termination Pending 

Sets the MU_ID state to be TERMINATION_PENDING. 

Transfer_Pending 


Sets the MU_ID state to be TRANSFER_PENDING. 
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e Instance_Number 


Compares the caller’s and MU_ID registry’s instance numbers. MU_ID reg- 
istry failures preventing the comparison result in MU_ID_OP_NOT_OK being 
returned to the caller. If the caller’s value is less than that in the registry, 
INSTANCE _NUM_NOT_OK is returned. If the MU_ID owning the instance 
number is not in the registry (it is not yet in the registry because its value is 
too high, or it was once in the registry but has been aged out), 

INSTANCE _NUM_OK is returned. Otherwise, INSTANCE NUM_OK is 
returned. 


UPM_CHECK_DUP_CONV_FAIL_REPORT 
This procedure is not explicitly specified. As discussed elsewhere (see the dis- 
cussion for DS_SEND_CHECK_CONV_FAIL, under “Program Structure” on 
page 146), some conversation failures cause both DS_Send and DS_Receive to 
initiate exception processing for the same MU_ID. This procedure is signalled 
by DS_SEND_CHECK_CONV_FAIL to determine whether a given REMU repres- 
ents such a duplicate (and extraneous) exception report for an already-known 
conversation failure. 


If the just-received REMU is reporting a conversation failure, and MU_ID state is 
TERMINATION_PENDING OF RETRY_PENDING, and DS_Send’s last action for this MU_ID 
was to send a SEMU reporting conversation failure, then 
DUP_CONV_FAIL_REPORT is returned to the caller. Otherwise, 
NOT_DUP_CONV_FAIL_REPORT is returned. 


DS Receive FSMs 


Data Structures 
DS_RCV uses the following data structures: 


MU_ID Registry: The MU_ID registry is a safe-stored data structure that 
records MU_ID, MU_!ID state and MU_ID-to-next_DSU_queue-entry mappings. It 
may be viewed as an array, each element of which contains four entries. The 
first entry is an MU_ID. The second is the state of the MU_ID. The third is a 
distribution locator, which is used to locate the distribution in the Mid-MU 
Restart queue. The fourth is the MU_ID’s instance number. 


When a DTMU prefix is received, the MU_ID is entered in the MU_ID registry, 
and the entry written to safe store. As the MU changes states, this entry is 
updated. When the distribution is purged, the distribution locator is replaced by 
a null entry. 


MU_IDs are assigned sequentially by the partner. Only contiguous blocks of 
entries containing the registry’s lowest MU_/Ds that are in the PURGED state and 
have null distribution locators are purged from the registry automatically (and 
their space reclaimed). All other entries are retained, unless explicitly purged 
by an operator. 


224 _ SNA/Distribution Services Reference 


Program Structure 
A logical decomposition of DS_Receive is given in figure Figure 46 on 
page 231. The following classes of routines exist in DS Receive: 


e DS Receive Manager 


The only FSM in this class of routines is “DS_RCV_MANAGER’” on 

page 232. It manages the transition between the LU 6.2 send and receive 
states, and also checks for the conversation idle condition, which causes 
the conversation to be terminated. 


e Receive-State Manager 


The only FSM in this class of routines is “DS RCV_RECEIVING” on 

page 237. This routine manages DE Receive while in the LU 6.2 receive 
state. It repeatedly receives DTMUs, DRMUs, DCMUs, SEMUs, CQMUs, and 
PRMUs from the partner DSU, parses them, and signals the appropriate 
handler. This routine returns to the caller only when the conversation ter- 
minates (normally or abnormally) or DS_Receive enters the LU 6.2 send 
state. 


e Send-State Manager 


The only FSM in this class of routines is “DS_RCV_SENDING” on page 234. 
This routine is active whenever DS _ Receive is in the LU 6.2 send state. It 
repeatedly reads CRMUs and REMUs from the control MU queue, and 
sends them to the partner DSU. When the control MU queue is empty, it 
returns control to the partner. 


e Distribution Receiving 


Different actions must be taken depending on the distribution’s high- or 
basic-integrity classification. These FSMs determine the distributions integ- 
rity (by checking for the presence or absence of the MU_ID value) and 
trigger the appropriate actions. The FSMs in this class are: 


“DS RCV_RECEIVE_DMU” on page 240. 


This FSM implements some high-integrity actions as well as some dis- 
tribution receiving actions. The distribution receiving action performed 
by this FSM is simply to signal “DS_RCV_ RECEIVE _DMU_NO MU_ID” on 
page 259. if the distribution uses basic integrity. 


— “DS RCV_MU_ID HANDLER” on page 244. 


This FSM implements some high-integrity actions as well as some dis- 
tribution receiving actions. The distribution receiving action performed 
by this FSM is simply to return a signal indicating that the distribution 
uses only basic integrity. Basic integrity is indicated by the lack of an 
MU_ID in the distribution’s encoding. 


¢ CQMU Receiving 


The only FSM in this class of routines is “DS _RCV_CQMU_ HANDLER” on 
page 265. This routine generates a CRMU containing the MU_ID state of 
the MU_ID contained in the just-received CQMU. MU_IDs higher than the 
registry’s highest received MU_ID are considered to be NOT_RECEIVED. | 
MU_IDs already purged from the registry are considered to be PURGED. 
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e SEMU Receiving 


The only FSM in this class of routines is “DS_ RCV_SEMU_HANDLER” on 
page 269. This routine first checks the SEMU’s instance number, if the 
instance number is too low, the SEMU is discarded and no further actions 
are taken. If the instance number is acceptable, the actions taken in 
response to a SEMU depend on the MU_ID state (e.g., NOT_RECEIVED, TERMI- 
NATED, Or SUSPENDED) and the retriability or non-retriability of the SEMU’s 
report code. Upon return from this FSM, the distribution will be either sus- 
pended or terminated. If suspended, the distribution is waiting to be 
restarted via a DCMU, the MU_ID state is SUSPENDED and a CRMU(sus- 
PENDED) has been generated. If terminated, the distribution has been 
deleted from the mid-MU restart queue, the server object has been deleted, 
the MU_ID state is TERMINATED and a CRMU(TERMINATED) has been gener- 
ated. 


e PRMU Receiving 


The only FSM in this class of routines is “DS_RCV_PRMU_HANDLER” on 
page 272. This routine examines DS _Receive’s MU_ID state of the PRMU’s 
MU_ID. |f DS_Receive’s MU_ID state is COMPLETED, TERMINATED or 
SUSPENDED, DS_Receive changes its MU_ID state to PURGED. Otherwise, the 
PRMU is ignored. 


e Bad/Unknown MU Receiving 


The only FSM in this class of routines is “DS_RCV_SEND_ERR_REMU” on 
page 248. (This FSM is also used for some high-integrity exception actions, 
which are discussed below.) This FSM is called when a just-received MU 
does not fall into any of the known MU categories (ODTMU, DRMU, DCMU, 
SEMU, CQMU, or PRMU). The exception action is to issue an LU 6.2 

Send Error, generate and send a REMU reporting the exception (and any 
other CMUs awaiting transmission), and deallocate the conversation. 


e Basic-iIntegrity Actions 


The only FSM in this class of routines is 
“DS_RCV_RECEIVE_DMU_NO_MU_ID” on page 259. This routine is similar 
to DS_RCV_RECEIVE_DMU, except that all MU_/D and mid-MU restart proc- 
essing is omitted, any exceptions cause the distribution to be discarded and 
no CMUs are used to report the success or failure of the distribution 
transfer. 


e High-integrity Actions 


These FSMs receive high-integrity distributions from the partner DSU. This 
involves 


— Checking the distribution’s MU_ID and instance number. 

— Entering the MU_/ID into the MU_ID registry (if appropriate). 
— Setting the MU_ID state to IN_TRANSIT. 

— Receiving and processing the entire distribution. 

— Signalling the responsibility acceptance FSMs. 


All exceptions are handled by the appropriate exception-handling routine, 
and the results of the reception are returned to the caller. The FSMs in this 
class are: - 
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“DS RCV_RECEIVE DMU”" on page 240. 


This FSM, assuming the MU_/ID can be honored correctly, repeatedly 
receives, parses, and processes the distribution. An entry is made on 
the mid-MU restart queue and manipulated as appropriate. The server 
object is written to the server. After the suffix has been received, the 
responsibility acceptance actions are performed to take responsibility 
for the distribution. Exceptions are processed by the appropriate excep- 
tion handler, and the success or failure of the transmission is returned 
to the caller. 


“DS RCV_MU_ID HANDLER” on page 244. 


This routine is signalled by DS _RCV_RECEIVE DMU to process the dis- 
tribution’s MU_ID and instance number. \|f the MU is a DTMU ora 
DRMU, the MU_ID state must be NOT_RECEIVED and the instance number 
must be ONE (1). If the MU is a DCMU, the MU_/D state must be sus- 
PENDED, and the instance number must be greater than the previously- 
received instance number. \|f the MU_ID and instance number are 
acceptable, the MU_ID state is changed to IN_TRANSIT. The success or 
failure of the MU_/D operations are returned to the caller. If the MU_ID 
is invalid, DS_Receive will inform its partner DSU of the exception and 
deallocate the conversation. Low instance numbers will cause the 
caller to ignore the distribution. Failures of the MU_ID registry will 
cause DS Receive to deallocate the conversation immediately. 


¢ High-Integrity Exception Actions 


These FSMs take the appropriate recovery actions for any exception that 
might occur while a distribution is being received from the partner DSU. 
The FSMs in this class are: 


“DS_RCV_SEND_ERR_REMU” on page 248. 


This FSM issues an LU 6.2 Send_Error verb to interrupt the partner’s 
transmission and generates a REMU describing an exception condition 
detected by DS Receive. It is used for “unrecognized MU type,” ”“MU_ID 
terminated,” and “MU_ID state mismatch exceptions,” since the excep- 
tion actions for these cases are identical. “Bad,” or unrecognized MUs 
are discussed above under ”Bad/Unknown MU Receiving.” An MU_ID 
state mismatch exists for a DT[MU or DRMU if the MU_ID state is sus- 
PENDED. An MU_/D state mismatch exists for a DCMU if the MU_ID state 
iS NOT_RECEIVED. An “MU_ID terminated” condition exists for a DTMU, 
DRMU or DCMU if the MU_ID state is TERMINATED. The exception actions 
taken by this FSM are: 


— To stop the partner’s transmission by using a Send _ Error LU 6.2 
verb. 
— To generate a REMU informing the partner of the exception. 


In addition to these actions, “MU_ID state mismatch” condition causes 
DS_Receive to send all waiting CMUs to the partner, and deallocate the 
conversation. 


“DS RCV_SEND ERR_CRMU” on page 256. 


This FSM issues an LU 6.2 Send_Error verb to interrupt the partner’s 
transmission and generates a CRMU informing the partner that the 
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MuU_ID just received is in either the COMPLETED or PURGED state. The 
exception actions taken by this FSM are: 


— To stop the partner’s transmission by using a Send_Error LU 6.2 
verb. 
— To generate a CRMU informing the partner of the MU_ID state. 


— “DS RCV_SEND_ERR” on page 246. 


This FSM issues an LU 6.2 Send _ Error verb to interrupt the partner’s 
transmission. When using parallel sessions, network delays may cause 
MUs to arrive at the receiving DSU in an order different from the order 
sent by the partner DSU. When such MUs are associated with different 
MU_!IDs, the reordering is inconsequential. When reordered MUs refer 
to the same MU_/D, the reordering may affect the processing of the 
MU_!ID. \f the reordered MUs are only CMUs, the protocols are robust 
enough to recover and allow the MU_iDs to be processed properly (pos- 
sibly at the cost of extra CMUs being generated). If the reordering 
involves distribution MUs, the situation is more serious. For example, 
suppose a tardy REMU were associated with the wrong DCMU: the 

DS_ Send process might initiate exception processing and attempt to ter- 
minate the distribution while DS_Receive was forwarding it on to the 
destination. To handle this latter case, each DMU is assigned an 
instance number, and CMUs carry the instance number of the DMU to 
which they refer. CMUs with obsolete instance numbers are simply 
ignored. 


DMUs with obsolete instance numbers are ignored logically. An LU 6.2 
Send_Error verb is issued to terminate the transmission (to save band- 
width), but no REMU is generated. Of course, DS_Receive enters the 
LU 6.2 send state upon issuing the Send Error, and thus gets the oppor- 
tunity to send any waiting CMUs. 


— “DS _RCV_SUSP_TERM” on page 250. 


This FSM suspends or terminates (as appropriate) a distribution. When 
a DS_Send is transmitting a DMU and encounters an exception condi- 
tion, it issues an LU 6.2 Send _Error verb to inform DS_Receive that the 
DMU’s transmission is being interrupted. Upon receiving this 
Send _ Error, this FSM is signalled to attempt suspending the distribution 
for later restart via a DCMU. If this suspension is successful, the MU_ID 
state is set to SUSPENDED. If such a suspension is not possible, 

DS Receive deletes the distribution and puts the MU_ID into TERMINATED 
state. 


This FSM is also signalled if, while receiving a distribution, DS_Receive 
detects that the partner DSU has violated DS’s use of the LU 6.2 basic 
conversation verbs. An example of such a protocol error is for 
DS_Send to issue a Receive_And_Wait verb while transmitting a distrib- 
ution. The distribution being received is discarded; the MU_ID is put 
into TERMINATED state. 


— “DS RCV_SEND_ERR_SUSP_TERM_REMU” on page 252. 


This FSM issues an LU 6.2 Send _ Error verb to interrupt the partner’s 
transmission, suspends or terminates the distribution (as appropriate), 
and generates a REMU describing the exception condition detected by 
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DS_ Receive. It is signalled if DS_Receive, while receiving a distribution, 
detects an exception in the queue manager, parser, or server. It is also 
signalled if DS Receive, after successfully receiving a distribution, fails 
to accept responsibility for it. 


An LU 6.2 Send _Error is issued to terminate the distribution’s trans- 
mission. If the exception is restartable via a DCMU, and DS Receive is 
capable of restarting the distribution, the distribution is suspended on 
the mid-MU restart queue, the server object is saved, and the MU _/D is 
put into SUSPENDED state. Otherwise, the distribution is discarded and 
the MU_ID is put into TERMINATED state. A REMU is generated to inform 
the partner DSU of the exception. _ 


— “DS _RCV_REMU_SUSP_TERM” on page 254. 


This FSM generates a REMU describing an exception condition detected 
by DS_Receive, and suspends the distribution (to be restarted via a 
DCMU) or discards it (if suspension is not possible or appropriate). It is 
signalled whenever DS _ Receive is receiving a distribution and the LU 
6.2 conversation with the partner fails. Such failures can be detected 
not only from the Receive _And_Wait verbs issued to receive the DMU, 
but from Send _ Error verb issued during 

DS _RCV_SEND_ERR_SUSP_TERM_REMU processing. 


If the distribution can be restarted via a DCMU, it and the associated 
server object are saved and the MU_ID put into SUSPENDED state. Other- 
wise, the distribution is discarded and the MU_ID put into TERMINATED 
state. | | | 


¢ Responsibility Acceptance Actions 


The only FSM in this class of routines is “DS _RCV_ENQ SCHED” on 

page 262. This FSM is signalled to accept responsibility of a distribution 
(either basic or high integrity) that has been received successfully. It 
creates a router-director queue entry for the distribution, schedules 
DS_Router_Director, changes the MU_/D state to COMPLETED and releases 
the just-created router-director queue entry. If all these operations 
succeed, a CRMU(COMPLETED) is generated. If any of the above operations 
fail, the distribution is left unchanged, just as it was when the FSM was 
signalled--no entry is left on the router-director queue, and the MU_ID state 
is left in IN_-TRANSIT. (And any operations that were attempted are backed 
out.) 


e DS Receive Utility Routines 


These FSMs perform relatively simple, well-defined functions that are 
needed by various other FSMs in DS_Receive. The FSMs in this class are: 


— “DS RCV_SUSP_DIST” on page 274. 


This FSM suspends a partially received distribution. That is, the dis- 
tribution’s entry in the mid-MU restart queue is released (so that it may 
be accessed later, probably by a different instance of DS Receive), and 
a Terminate_Write server verb is issued (so that the server object may 
be accessed later). 
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— “DS RCV_DISCARD_DIST” on page 276. 


This FSM discards a distribution. The server object is deleted (and 
restartability terminated), and the distribution’s mid-MU restart queue 
entry is dequeued and discarded. 


— “DS _RCV_SEND_CONVERSATION_MGR’” on page 278. 


This FSM sends a single buffer to the partner DSU by issuing an LU 6.2 
Send Data verb. The outcome of the Send_ Data (LU 6.2 accepted the 
data without detecting an exception, a conversation failure was 
detected, the partner DSU issued a Send _Error, etc.) is returned to the 
caller. 


— “DS_RCV_MU_ID_REGISTRY” on page 280. 


This procedure manages DS_Receive’s access to the MU_ID registry. 
An MU_ID state may be assigned or inspected, or a just-received | 
instance number may be compared to the instance number in the reg- 
istry. (An MU containing an instance number that is too low is ignored.) 


—- “PREPARSER” on page 280 


This procedure inspects the initial LLID of an MU and returns the MU 
type (DTMU, DRMU, DCMU, SEMU, PRMU, or CQMU). It also identifies 
and returns the MU_/D and instance number, if appropriate. CMUs are 
parsed completely; if the CMU contains a format exception, or if an 
MU_ID or instance number is missing when required or otherwise 
invalid, BAD_MU is returned. If the initial LL’s ID is not recognized, 
UNKNOWN_MU is returned. — 
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Figure 46. DS_Receive Logical Structure 
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DS_RCV_MANAGER 


Function: This finite-state machine describes the functional processing for DS_Receive. This FSM is 
started by LU 6.2 on receiving an Attach, or by the operator via a START_TRANSACTION. If 
DS_Receive is started by LU 6.2 via Attach, it is initially in the LU 6.2 receive state. Otherwise, 
it is initially in the LU 6.2 send state. 


The primary processing of this FSM is done in states 3 (RECEIVING), 4 (SENDING) and 5 (IDLE 
TEST). When in RECEIVING state (state 3), DS_Receive is in the LU 6.2 receive state and is 
receiving distribution and control MUs from the partner. If DS Receive then receives the 
change direction indication from LU 6.2, it immediately attempts to send any waiting control 
MUs to the partner by signalling DS_RCV_SENDING. 


When in SENDING state (state 4), DS_Receive is in the LU 6.2 send state, and is sending CMUs 
to the partner. The lower-level FSMs signal DS_Receive to enter the LU 6.2 receive state by 
returning CHANGE DIRECTION. DS_RCV_MANAGER first checks to determine if an idle conver- 
sation exists by signalling IDLE DETECTOR. If an idle conversation does exist, the conversation 
is simply deallocated. If the conversation is not idle, DS_Receive goes into the LU 6.2 receive 
state by signalling DS_RCV_RECEIVING. 


An idle conversation exists whenever both of the following conditions hold: 


e When DS_Receive was last in the LU 6.2 receive state, it received no MUs from the partner 
DS_Send. 

e DS Receive, which is currently in the LU 6.2 send state, has had no control MUs to send to 
the partner DS_Send. 


This FSM gets control from one of the following: 
¢ Signals from higher-level finite-state machines or procedures: 


— from “FSM_SCHED MGR” on page 351 
— START_TRANSACTION 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS_RCV_SENDING” on page 234 
— CHANGE_DIRECTION 
— DEALLOCATE_LOCAL 
— DEALLOCATE_ FLUSH 
— DEALLOCATE ABEND 
— from “DS_RCV_RECEIVING” on page 237 
— CHANGE_DIRECTION 
— DEALLOCATE_LOCAL 
— DEALLOCATE ABEND 
— SEND CMU_AND_DEALLOCATE 


¢ Signals from machines providing common services: 


— from “IDLE_DETECTOR” on page 284 
— CHANGE_DIRECTION 
— DEALLOCATE_FLUSH 


° Signals from LU 6.2 presentation services 


—~ OK 

— ATTACH ; 

— ALLOCATION ERROR 
~— ALLOC_PARM ERROR 
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Signal LU 6.2 presentation services with ALLOCATE to establish the conversation with DS_Send. 
Signal LU 6.2 presentation services with GET_ATTRIBUTES. 

Signal DS_RCV_RECEIVING with START. 

Signal DS_RCV_SENDING with SEND. 


Notify operations of the exception condition. 
cali LU 6.2 icici services with DEALLOCATE specifying type(LOcaL). 
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DS _RCV_SENDING 


Function: This finite-state machine describes the functional processing for DS Receive while it is in the 


LU 6.2 send state. This FSM repeatedly finds a CMU on the control MU queue, sends it, and 


discards the queue entry. FSM IDLE_DETECTOR is also signalled. When the queue is emptied, 
a CHANGE_DIRECTION signal is returned to the caller. 


If the LU 6.2 conversation failure is detected, the CMU being sent is left on the queue to be 
sent by another instance of DS_Receive. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS _RCV_MANAGER” on page 232 
— SEND 


¢ Signals from machines providing common services: 


— from “DS _RCV_SEND_CONVERSATION_MGR” on page 278 
— OK 
— CONVERSATION FAILURE 
— PROG_ERROR 
— PROTOCOL_ERROR 
— from “QUEUE_MGR” on page 357 
— QUEUE_OK 
— QUEUE NOT_OK 
— QUEUE EMPTY 
— from “IDLE_DETECTOR” on page 284 
— nothing returned from this FSM 


PROTOCOL ERROR 
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Signal QUEVUE_MGR with READQ, specifying queue(CONTROL_MU_QUEUE). 


Signal IDLE DETECTOR with SOMETHING_SENT. 
Signal DS_RCV_SEND_CONVERSATION_MGR with SEND_BUFFER to send the control MU to the 
partner DSU. 


Notify operations of the exception condition. 
Signal QUEVUE_MGR with HOLD specifying queue(CONTROL_MU_QUEUE) for this connection. Nothing is 
to be sent to the partner DSU. Signal caller with DEALLOCATE_FLUSH. 


a 
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Notify operations of the exception condition. 
Signal QUEVE_MGR with HOLD specifying queue(CONTROL_MU_QUEUE) for this connection. Nothing is 
to be sent to the partner DSU. Signal caller with DEALLOCATE_LOCAL. 


Notify operations of the exception condition. 
Signal caller with DEALLOCATE_ABEND. 


Notify operations of the exception condition. 
Signal QUEVE_MGR with HOLD specifying queue(CONTROL_MU_QUEUE) for this connection. Nothing is 
to be sent to the partner DSU. Signal caller with DEALLOCATE_ABEND. 
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DS_RCV_RECEIVING 


Function: 


This finite-state machine controls DS_Receive in the LU 6.2 receive state. A buffer is received 


from LU 6.2, and the initial LLID examined (states 1 and 2). This LLID indicates that the MU 


being received is a DTMU, DCMU, DRMU, CQMU, PRMU, SEMU, or an unknown MU type. An 

appropriate handler is called for each MU type (state 3). The handler’s results are returned to 
the caller. If an exception occurs (such as an LU 6.2 conversation failure), it is also returned to 
the caller. 


This FSM gets control from one of the following: 


Signals from higher-level DS_Receive finite-state machines or procedures: 


from “DS_RCV_MANAGER?” on page 232 


Signals from lower-level DS_Receive finite-state machines: 


from “DS_RCV_RECEIVE_DMU” on page 240 
— MU_OK 

— CONVERSATION_FAILURE 

— SEND_SIDE_EXCEPT 

— RCV_SIDE_EXCEPT 

— PROTOCOL_ERROR 

— MU_ID_STATE_MISMATCH 

— DS_RCV_SYSTEM_ERROR 

from “PREPARSER” on page 280 

— DMU 

— CQMU 

— PRMU 

— SEMU 

— UNKNOWN_MU 

— BAD_CMU 

from “DS_RCV_CQMU_HANDLER” on page 265 
— MU_OK 

— MU_NOT_OK 

from “DS_RCV_PRMU_HANDLER” on page 272 
— MU_OK 

— MU_NOT_OK 

from “DS_RCV_SEMU_HANDLER” on page 269 
— MU_OK 

— MU_NOT_OK 

from “DS_RCV_SEND_ERR_REMU” on page 248 
— CONVERSATION _FAILURE 

— UNREC_MU_TYPE 

— DS_RCV_SYSTEM_ERROR 


Signals from machines providing common services: 


from “RCV_BUFFER_MGR” on page 282 
— OK 

— CHANGE_ DIRECTION 

— CONVERSATION_FAILURE 

— PROG_ERROR 

— PROTOCOL_ERROR 

— DEALLOCATE_ NORMAL 

from “IDLE DETECTOR” on page 284 

— no signals received from this FSM 


Chapter 3. 


Implementation Model 


237 


_— (elslelelele “ 

RCV MU MU | 
RESET | BUFF | TYPE MU_ID 
por | 6 | or 


ee o7 | 8 
Tope | 


fe) 
> 
a 
— 
Fi 
i 
4 

i 
: 
Pi 
~ 


| 
| 
| 
| 
i 
| 
| 
i 
{ 


| 


{ 
i 
i 


, | / 


i 
I 
( 
j 
{ 
| 
i 


j 
5 
; 
; 


i 


{ 
{ 
i 
| 


_— 
~~ 


1 
i 
i 
| ~ 7 


PROG ERROR 
DEALLOCATE NORMAL 
CONVERSATION FAILURE 
PROTOCOL ERROR 

SEND SIDE EXCEPT 

RCV SIDE EXCEPT a 
DS RCV SYSTEM ERROR 
MU ID STATE MISMATCH 
UNREC MU TYPE 


Jenanczomecnon [7 | |) [7 |r |r) [7] 
a / 
/ / 


=a 
?) 


~— 
oO 


—_h, 
x 
| 
a ~ _— — ~ ~ ~~ ~ ~— ~ 
{ 
i 


“—™ F™! PF ™m PP ™ PF ™m FM FM FP Om PO OF me 


‘ 
1 
; 
‘ 
i 
‘ 


i i 
{ A 
{ j 
| 
| | 
, f 
H i 
| 
! : 
} i 
i i 
{ _f 


| 
i 
| 
t 
| 
| 


BSN 
=e 


o> 
a 


! if 

{ i 

| Con 

i : 

i | 
F 


~~ FM™ F ™ 


~l 

— 
| 
a“ =~ ~ =~ =— =~ 
: i 
‘ : 
i i 


4 
| 
| 
{ 
{ 
i 
H 
{ 
{ 
{ 
{ 
i 
{ 
| 
| 
i 
| 
| 
| 
i 


le 
i 
i 
i 
; 
i 
i 
‘ 
‘ 
i 
; 
} 
| 


i 
| 


i 
: 
; 
1 
j 
i 
i 
{ 
i 
i 
j 
I 
i 
j 
i 
4 
! 
i 
i 


BAD CMU 


P 


MU NOT OK 


238 SNA/Distribution Services Reference 


Signal RCV_BUFFER_MGR with RECEIVE_BUFFER. 


Signal IDLE_DETECTOR with SOMETHING RECEIVED. 
Signal PREPARSER with RETURN_MU_TYPE. (For control MUs, the PREPARSER either parses the 
CMU completely, or signals the parser to complete the parsing.) 


Signal caller with CHANGE_DIRECTION. | 


Signal caller with DEALLOCATE_LOCAL. 


Notify operations of the exception condition. 
Signal caller with DEALLOCATE_ABEND. 
f Signal DS_RCV_RECEIVE_DMU with DECODE. 
Signal DS_RCV_CQMU_HANDLER with START 


Signal DS_RCV_PRMU_HANDLER with START 


Signal DS_RCV_SEMU_HANDLER with START. 
Signal DS_RCV_SEND_ERR_REMU with UNREC_MU_TYPE. 


Notify operations of the exception condition. 
Signal caller with SEND-CMU_AND_DEALLOCATE. 
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DS_RCV_RECEIVE_DMU 


Function: 


This is DS_Receive’s “distribution handler.” It receives and parses a high-integrity DTMU, 
DRMU or DCMU, or signals DS_RCV_RECEIVE_DMU_NO_MU_ID to handle a basic-integrity 
DTMU or DRMU. The major processing in this FSM is in two loops: states 4 and 5 are a loop 
for receiving and parsing the DMU. States 4, 5 and 6 are a loop for receiving and writing the 
server object. When the DMU’s suffix has been received successfully, a Terminate_Write 
server verb is issued and DS_RCV_ENQ_ SCHED is signalled to accept responsibility for the dis- 


tribution. 
This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Receive finite-state machines: 


— from “DS RCV_RECEIVING” on page 237 
— DECODE 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS _RCV_ENQ SCHED” on page 262 
— ENQ SCHED OK 
— ENQ SCHED _NOT_OK 
— ENQ SCHED _OK_DEALLOCATE 
— from “DS _RCV_MU_ID_HANDLER” on page 244 
— MU_ID_OK 
— BAD_INSTANCE_NUM 
— MU_ID_NOT_USED 
— DS _RCV_SYSTEM_ERROR 
— MU_ID_STATE_MISMATCH 
— MU_ID_TERMINATED 
— MU_ID_COMP_PURG 
— from “DS_RCV_SEND_ERR_REMU” on page 248. 
— CONVERSATION_FAILURE 
— MU_ID_STATE_MISMATCH 
— DS _RCV_SYSTEM_ERROR 
— MU_ID_TERMINATED 
— from “DS_RCV_SEND_ERR_CRMU” on page 256. 
— CONVERSATION FAILURE 
— MU_ID_COMP_PURG 
— DS _RCV_SYSTEM_ERROR 
— from “DS_RCV_RECEIVE_DMU_NO_MU_ID” on page 259. 
— MU_OK 
— DS _RCV_SYSTEM_ERROR 
— RCV_SIDE_EXCEPT 
— SEND_SIDE_EXCEPT 
— CONVERSATION FAILURE 
— PROTOCOL_ERROR 
— from “DS_RCV_SEND_ERR” on page 246. 
— SEND _ERROR_GENERATED 
— CONVERSATION FAILURE 
— from “DS_RCV_SEND_ERR_SUSP_TERM_REMU” on page 252. 
— DS _RCV_SYSTEM_ERROR 
— SEND_ERR_SUSP_TERM_REMU 
— CONVERSATION _ FAILURE 
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— from “DS _RCV_SUSP_TERM” on page 250. 
— PROG _ERR_RCVD 
— DS _RCV_SYSTEM_ERROR 
— PROTOCOL_ERROR_RCVD 
— from “DS_RCV_REMU_SUSP_TERM” on page 254. 
— DS RCV_SYSTEM_ERROR 
— REMU_SUSP_TERM 


¢ Signals from machines providing common services: 


— from “RCV_BUFFER_MGR" on page 282 
— OK 
— CONVERSATION _ FAILURE 
— PROTOCOL_ERROR 
— DEALLOCATE_NORMAL 
— PROG_ERROR 
— CHANGE_DIRECTION 
— from “QUEUE MGR” on page 357 
— QUEUE _OK 
— QUEUE_NOT_OK 
— “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
— SPECIFIC_SERVER_EXCEPTION 


¢ Signals from “PARSER” on page 359: 


— PARSE_OK 

— PARSE_OK_OBJECT 
— PARSE COMPLETE 
— PARSE _NOT_OK 
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Output 
Code | 
Signal DS_RCV_MU_ID_HANDLER with the MU type (DTMU, DRMU or DCMU). 


If the MU is a DTMU and mid-MU restart capability is provided, then signal QUEUVUE_MGR with 
WRITEQ, specifying queue(MID_MU_RESTART_QUEUE). If this operation fails, implementations may reject 
the distribution. Or, they may choose to receive the distribution without mid-MU restart capability. 
The former case is modeled. | 

If the MU is a DCMU, then signal QUEVUE_MGR with READO specifying queue(MiID_MU_RESTART_QUEUE) 
to fetch the previously-received portion of the distribution. 

If the MU is a DRMU, or a DTMU where no mid-MU restart capability is provided, then processing 
continues as though QUEVE_MGR returned QUEUE OK. 


Signal DS_RCV_SEND_ERR_SUSP_TERM_REMU with START to process the error appropriately. 
Signal RCV_BUFFER_MGR with RECEIVE_BUFFER to receive information from LU 6.2. 


Signal SERVER_MGR with WRITE to write the just-received portion of the server object. 
SERVER_MGR will issue a Initiate_Write, if appropriate. 


Signal SERVER_MGR with TERMINATE_WRITE with termination_type NORMAL to terminate 
restartability. If no server object has been processed (and therefore no Initiate_Write has been 
issued), processing continues with OBJECT_OK. 


Signal DS_RCV_SUSP_TERM with PROG_ERR to process the error appropriately. 
Signal DS_RCV_REMU_SUSP_TERM with START to process the error appropriately. 
Signal DS_RCV_SUSP_TERM with PROT_ERR. | 


Signal DS_RCV_ENQ SCHED with ENQ_SCHED to place the distribution on the router-director queue, 


schedule DS_Router_Director, set the MU_ID registry entry and build and enqueue the CRMU on the 
control MU queue. 


the sender exception protocols should be followed. | 


Signal caller with PROTOCOL_ERROR to indicate that a protocol error has occurred in the conversa- 
tion between DS_Send and DS_Receive. 


Signal DS_RCV_SEND_ERR_REMU with MU_ID_STATE_MISMATCH. 


Signal caller with MU_ID_STATE_MISMATCH to indicate that the received MU (or an MU_!ID_state 


implied by the MU) is inconsistent with the MU_/D_state in the registry. 
Signal DS_RCV_SEND_ERR_CRMU with MU_ID_COMP_PURG to indicate that the received MU_/D 


has an MU_/D state of COMPLETED or TERMINATED. 
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DS_RCV_MU_ID_HANDLER 


|Function: 


This finite-state machine does the initial MU_/D processing when a distribution MU is first 
received. If no MU_ID is present in a DTMU or DRMU, the caller is informed that the distrib- 
ution does not use MU_/Ds. If the MU is a DTMU or a DRMU, the MU_ID state should be 
NOT_RECEIVED. Otherwise an error exists. | 


For DCMUs, the instance number is checked; if it is less than or equal to the instance number 
in the MU_ID registry, the DCMU is considered tardy, and ignored. If the instance number is 
greater than the one in the registry, the MU_/ID state is checked to see that it is SUSPENDED. 


Otherwise, an error exists. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS Receive finite-state machines or procedures: 


— from “DS_RCV_RECEIVE_DMU” on page 240 
— DTMU 
— DRMU 
— DCMU 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS_RCV_MU_ID_REGISTRY” on page 280 
— NOT_RECEIVED 
— IN TRANSIT 
— SUSPENDED 
— TERMINATED 
_— COMPLETE 
— PURGED 
— INSTANCE_NUM_OK 
— INSTANCE_NUM_EQUAL 
— INSTANCE _NUM_LOW 
— MU_ID_OP OK 
— MU_ID_OP_NOT_OK 
— MU_ID NOT_USED 


¢ Signals from machines providing common services: 


— from system operator 
— OP_CONTINUE 
— OP_ABORT 
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INSTANCE ‘NUM HIGH» 
INSTANCE NUM EQUAL 
INSTANCE NUM LOW — 


NOT RECEIVED 


TERMINATED 
COMPLETE 


| MU ID NOT USED 


MU ID OP OK 
MU ID OP NOT OK 


Output | Function 
Code 
Signal DS_RCV_MU_ID_REGISTRY with INSPECT. 


Signal DS_RCV_MU_ID_REGISTRY with INSTANCE_NUMBER to compare the DCMU’s instance 
number with the MU_ID registry’s instance number. The DCMU’s instance number must be greater 
than the MU_ID registry’s instance number, and the MU_ID registry’s number is updated to be equal 
to the DCMU’s. 


Notify operations of the exception condition. | 
Signal caller with BAD_INSTANCE_NUM. 
Signal caller with DS_RCV_SYSTEM_ERROR. 


Notify operations of the exception condition. 
Signal caller with MU_ID_STATE_MISMATCH. 


Signal DS_RCV_MU_ID_REGISTRY with IN_ TRANSIT. 
Signal caller with MU_ID_NOT_USED. 

oe caller with MU_ID_OK. 

Signal caller with MU_ID_ TERMINATED. 


Signal caller with MU_ID_COMP_PURG to indicate that the just-received MU_ID has an MU_ID state 
Of COMPLETED Or PURGED. 
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DS_RCV_SEND_ERR 


Function: This finite-state machine is signalled when an exception is encountered while receiving a dis- 
tribution and the immediate exception action is simply to issue a Send_Error LU 6.2 verb. The 
Send_Error verb terminates the transmission. (No REMU is generated, the distribution in ques- 
tion is not suspended or discarded, and the MU_ID state is not modified.) This FSM is signalled 
when: 


¢ A DCMU with an obsolete instance number is received. Effectively, the DCMU is ignored, 
but no REMU is generated. 


This FSM gets control from one of the following: 


* Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS_RCV_RECEIVE_DMU” on page 240 
— START 


* Signals from LU 6.2 presentation services 


OK 
DEALLOCATE_NORMAL 
RESOURCE FAILURE 


DEALLOCATE NORMAL 
RESOURCE FAILURE 


Signal LU 6.2 presentation services with SEND_ERROR. 
Signal caller with SEND_ERROR_GENERATED. 
Signal caller with CONVERSATION_FAILURE. 
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DS_RCV_SEND_ERR_REMU 


Function: This finite-state machine is signalled when an exception has been encountered while receiving 
a distribution and the immediate exception action is to issue an LU 6.2 Send_Error verb to 
terminate the transmission, and generate a REMU informing the partner DSU of the exception 
code. Eventually, DS_Receive will send this REMU (and any other CMUs waiting to be sent) to 


the partner. The conversation will be deallocated (if appropriate). This FSM is signalled in the 
following cases: 


¢ by DS_RCV_RECEIVING when an MU of an unrecognized type is received. 

¢ by DS _RCV_RECEIVE_DMU when an MU with an MU_ID state mismatch is detected. MU_/ID 
state mismatches most often reflect an incompatibility between the DMU and the MU_ID 
registry. For example, receiving a DT[MU whose MU_/D state is anything other than 
NOT_RECEIVED or TERMINATED is such an incompatibility. Receiving a DCMU with a correct 
instance number and an MU_!D state of other than SUSPENDED or TERMINATED is another 
example. 

¢ by DS_RCV_RECEIVE_DMU when an MU_ID-terminated condition is detected. This condi- 
tion exists whenever a DMU is received, but the MU_/D state is TERMINATED. This condition 
may be the result of a simple race condition, in which a SEMU outruns its associated DMU. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Receive finite-state machines or procedures: 
— from “DS_RCV_RECEIVING” on page 237 
— UNREC_MU_TYPE 
— from “DS_RCV_RECEIVE_DMU” on page 240 


— MU_ID_STATE_MISMATCH 
— MU_ID TERMINATED 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE _OK 
— QUEUE NOT_OK 


¢ Signals from LU 6.2 presentation services 


—- OK 
— ALLOCATION_ERROR 
— RESOURCE_FAILURE 
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Signal LU 6.2 presentation services with SEND_ERROR. 


Build a REMU with the appropriate exception code and enqueue it on the control MU queue by sig- 
nalling QUEVUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). 


a 
[Soa eter win REC MUNPE 
a 
— 
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: 
a [Signal calor with MU_ID_TERMNATED.———SSOSC~“~S*S*~“~“~S~S 
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DS_RCV_SUSP_TERM 


Function: This finite-state machine is signalled when an exception has been encountered while receiving 
a distribution and the immediate exception action is to suspend or discard the distribution 
(depending on the specific exception and whether the distribution could be restarted with a 
DCMU). This FSM is signalled when: 


¢ DS_RCV_RECEIVE_DMU expected DMU data from an LU 6.2 Receive_And_Wait verb, but 
received a PROG_ERROR indication instead. The PROG_ERROR indicates that the partner DSU 
has encountered some exception condition preventing it from continuing to transmit the 
DMU. The partner will transmit details of the exception in a SEMU, but until the SEMU is 
received, DS_Receive interrupts its processing of this distribution. 


DS_Receive presumes that the exception will be retriable, suspending the distribution if 
possible, and setting the MU_/D state to SUSPENDED. This allows the distribution to be 
restarted via a DCMU if the partner so chooses. 


Otherwise, the distribution is discarded, and the MU_/D state set to TERMINATED. In this 


case, if the exception is retriable, the partner retries it from the beginning with a different 
MU_ID. 


* DS _RCV_RECEIVE_DMU detects that the partner DSU has violated DS use of the LU 6.2 
basic conversation protocol boundary. Protocol errors are not retriable. The distribution is 
discarded, and the MU_/D state changed to TERMINATED. DS_Receive will deallocate the con- 
versation. 


This FSM gets control from one of the following: 
* Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS_RCV_RECEIVE_DMU” on page 240 
— PROG ERR 
— PROT_ERR 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS_RCV_SUSP_DIST” on page 274 
— DIST_SUSPENDED 
— SUSPEND FAILED 
— from “DS_RCV_DISCARD_DIST” on page 276 
— DIST_DISCARDED 
— DISCARD_FAILED 
— from “DS _RCV_MU_ID_REGISTRY” on page 280 
— MU_ID OP_OK 
— MU_ID_OP_NOT_OK 
— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_WITHOUT_MID_MU 
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DS_RCV_SEND_ERR_SUSP_TERM_REMU 


Function: 


This finite-state machine is signalled when an exception is encountered while receiving a dis- — 
tribution and the immediate exception action is to issue an LU 6.2 Send_Error verb, generate a 
REMU informing the partner DSU of the report code, and suspend the distribution (if appro- 
priate) or discard it (if suspension is not appropriate). 


The FSM first issues an LU 6.2 Send_Error verb (state 1). If the distribution can be restarted 
via a DCMU, the distribution is retained and the MU_/D state changed to SUSPENDED (FSM states 
3 and 4). Otherwise, the distribution is discarded and the MU_ID state set to TERMINATED (FSM 
states 3 and 5). A REMU is generated to inform the partner DSU of the exception report code 
(state 6). This FSM is signalled when 


e DS RCV_RECEIVE_DMU detects a queue, parser or server exception while receiving a 
DMU. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_ Receive finite-state machines or procedures: 


— from “DS _RCV_RECEIVE_DMU” on page 240 
— START 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS _RCV_SUSP_DIST” on page 274 
— DIST SUSPENDED 
— SUSPEND_FAILED 
— from “DS _RCV_DISCARD_DIST” on page 276 
— DIST_DISCARDED 
— DISCARD_FAILED 
— from “DS _RCV_MU_ID_REGISTRY” on page 280 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 
— from “DS _RCV_REMU_SUSP_TERM” on page 254 
— DS_RCV_SYSTEM_ERROR 
— SUSP_TERM | 
— “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_WITHOUT_MID_MU 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE_OK 
— QUEUVE_NOT_OK 


¢ Signals from LU 6.2 presentation services 


— OK 
— DEALLOCATE_NORMAL 
— RESOURCE_FAILURE 
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Signal DS_RCV_MU_ID_REGISTRY with SUSPENDED. 
Signal DS_RCV_MU_ID_REGISTRY with TERMINATED. 


Build a REMU with the appropriate exception code and enqueue it on the control MU queue by sig- 
nalling QUEUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). 


Signal caller with DS_RCV_SYSTEM_ERROR. 
Signal caller with SEND_ERR_SUSP_TERM_REMU. 
Signal caller with CONVERSATION_FAILURE. 
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DS_RCV_REMU_SUSP_TERM 


Function: This finite-state machine is signalled whenever an exception is detected while receiving a dis- 
tribution, and the immediate exception action is to generate a REMU informing the partner of 
the report code, and to suspend or discard the distribution. The distribution is suspended if the 
exception is retriable and the distribution can be restarted with a DCMU. Otherwise, the dis- 
tribution is discarded. 


In states 2 and 3, the distribution is suspended and the MU_ID state is set to SUSPENDED if the 
exception is retriable and the distribution can be restarted via a DCMU. Otherwise, the distrib- 
ution is discarded and the MU_ID state set to TERMINATED (FSM states 2 and 4). Finally, a REMU 
is generated (state 6). 


This FSM is signalled when 


e A conversation failure is detected during receipt of a DMU or during a DMU’s exception 
processing. The REMU generated here will be sent to the partner by a different instance of 
DS_Receive, and on a different conversation. (Even though conversation failure is 
retriable, this FSM handles NOT_RETRIABLE exceptions because the conversation failure 


might occur during a non-retriable exception’s processing. In such a case, the distribution 
is discarded.) 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS _RCV_RECEIVE_DMU” on page 240 
— START 

— from “DS _RCV_SEND_ERR_SUSP_TERM_REMU” on page 252 
— START 


e Signals from lower-level DS_Receive finite-state machines: 


— from “DS_RCV_SUSP_DIST” on page 274 
— DIST_SUSPENDED 
— SUSPEND_FAILED 

— from “DS_RCV_DISCARD_DIST” on page 276 
— DIST_DISCARDED 
— DISCARD_FAILED 

— from “DS_RCV_MU_ID_REGISTRY” on page 280 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 

— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITH_MID_MU 
— RETRIABLE_WITHOUT_MID_MU 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE OK 
— QUEUE_NOT_OK 
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Signal DS_RCV_SUSP_DIST with START. 


ld «| Signal DS_RCV_MU_ID_REGISTRY with SUSPENDED. 
fe | Signal DS_RCV_MU_ID_REGISTRY with TERMINATED. 


Build a REMU with the appropriate exception code and signal QUEVUE_MGR with WRITEQ specifying 
queue(CONTROL_MU_QUEUE). 


Notify operations of the exception condition. 
Signal caller with REMU_SUSP_TERM. 


Signal caller with REMU_SUSP_TERM. 
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DS_RCV_SEND_ERR_CRMU 


This finite-state machine is signalled when an exception has been encountered while receiving 
a distribution and the immediate exception action is to issue an LU 6.2 Send_Error verb to 
terminate the transmission, and generate a CRMU informing the partner DSU that the MU_ID 
state was already COMPLETED or PURGED. Eventually, DS_Receive will send this CRMU (and any 
other CMUs waiting to be sent) to the partner. The conversation will be deallocated (if appro- 
priate). This FSM is signalled by DS_RCV_RECEIVE_DMU when an MU whose MU_ID state is 
already COMPLETED Or PURGED is received. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS_RCV_RECEIVE_DMU” on page 240 
— MU_ID_COMP_PURG 


¢ Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUVE_OK 
— QUEUE NOT_OK 


* Signals from LU 6.2 presentation services 


— OK 
— ALLOCATION_ERROR 
— RESOURCE_FAILURE 


SEND CRMU 
CONV FAIL 


QUEUE NOT OK 
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Signal LU 6.2 presentation services with SEND_ERROR. 


Build a CRMU with the appropriate exception code and enqueue it on the control MU queue by sig- 
nalling QUEUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). 


fc _—_| Signal caller with MU_ID_COMP_PURG. 
'd -—_{ Signal caller with DS_RCV_SYSTEM_ERROR. 
fe ‘| Signal caller with CONVERSATION_FAILURE. 


Chapter 3. Implementation Model 257 


258 = SNA/Distribution Services Reference 


DS_RCV_RECEIVE_DMU_NO MU _ID 


Function: 


Note: 


This finite-state machine is signalled to control the receiving and parsing of a basic-integrity 
DTMU or DRMU. States 2 and 3 form a loop receiving and parsing the DMU’s control informa- 
tion. States 2, 3 and 4 form a loop receiving and storing the server object. State 5 signals 
DS_RCV_ENQ_ SCHED to accept responsibility for the distribution, putting it on the router- 
director queue, and scheduling DS_Router_Director. 


A basic-integrity distribution does not use an MU_!D or CMUs to control its transfer from one 
DSU to the next. Any exception (including exceptions unrelated to the distribution, such as 
conversation failure) results in the distribution being discarded. 


An elective (not shown in this model) allows a REMU to be generated or: receiver-detected 
errors (i.e., those for which RCV_SIDE_EXCEPT CONVERSATION_FAILURE or 
PROTOCOL_ERROR are returned to the caller). No MU_ID will be included in this REMU. 


This FSM gets control from one of the following: 


Signals from higher-level DS_Receive finite-state machines: 


— from “DS _RCV_RECEIVE_DMU” on page 240 
— START 


Signals from lower-level DS_Receive finite-state machines: 


— from “DS _RCV_ENQ SCHED” on page 262 
— ENQ_SCHED_OK 
— ENQ SCHED_NOT_OK 
— ENQ SCHED _OK_DEALLOCATE 
— from “DS _RCV_DISCARD_DIST” on page 276 
— DIST_DISCARDED 
— DISCARD_FAILED 


¢ Signals from finite-state machines providing common services: 


— from “RCV_BUFFER_MGR” on page 282 
— OK 
— CONVERSATION_FAILURE 
— PROTOCOL_ERROR 
— DEALLOCATE_NORMAL 
— PROG_ERROR 
CHANGE_DIRECTION 
= “SERVER. MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
— SPECIFIC_SERVER_EXCEPTION 


¢ Signals from LU 6.2 presentation services 


—- OK 

— ALLOCATION_ERROR 

— DEALLOCATE_NORMAL 
— RESOURCE_FAILURE 


¢ Signals from “PARSER” on page 359: 


— PARSE_OK 

— PARSE_OK OBJECT 
— PARSE COMPLETE 
— PARSE_NOT_OK 
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Output 


Signal SERVER_MGR with WRITE to write the just-received portion of the server object. 


SERVER_MGR will issue a Initiate_Write, if appropriate. 


Signal SERVER_MGR with TERMINATE_WRITE. If no server object has been processed (and there- 
fore no initiate write has been issued), processing continues with OBJECT_OK. 


Signal LU 6.2 presentation services with SEND_ERROR. 


server object (if any). 


Signal DS_RCV_ENQ SCHED with ENQ_SCHED to place the distribution on the router-director queue 
and schedule DS_Router_Director. 


the sender exception protocols should be followed. 


Signal caller with PROTOCOL_ERROR to indicate that a protocol error has occurred in the conversa- 


tion between DS_Send and DS_Receive. 


_— Signal DS_RCV_DISCARD_DIST with START to discard the partially-received distribution and its 
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DS_RCV_ENQ SCHED 


This finite-state machine describes the functional processing in DS_Receive to accept responsi- 
bility for a distribution. In states 1-4, it places the distribution on the router-director queue, 
updates the MU_/D state to COMPLETED, and schedules the DS_Router_Director. If any of these 
operations fails, the others are either not attempted or backed out. State 5 removes the dis- 
tribution from the mid-MU restart queue. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines: 


— from “DS_RCV_RECEIVE_DMU” on page 240 
— ENQ SCHED 

— from “DS_RCV_RECEIVE_DMU_NO_MU_ID” on page 259 
— ENQ_ SCHED 


¢ Signals from lower-level DS_Receive finite-state machines: 


—- “DS RCV_MU_ID_REGISTRY” on page 280 
— see output code D. 


¢ Signals from finite-state machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE _OK 
— QUEUE_NOT_OK 
— from “FSM_SCHED_ MGR” on page 351 
— SCHED_FUNCTION_OK 
— SCHED_FUNCTION_NOT_OK 
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Output 
Code 


Signal QUEVE_MGR with WRITEQ specifying queue(ROUTER_DIRECTOR_QUEUE) to place the distribution 


on the router-director queue. 


Signal FSM_SCHED_MGR with START_REQUEST to schedule DS_Router_Director. 


Signal caller with ENQ_SCHED_NOT_OK to indicate that an error occurred in placing the distribution 
on the router-director queue, or in scheduling DS_Router_Director. Cleanup of the router-director 
queue has taken place. 


As an atomic operation (i.e., all or none of the following operations must succeed), perform the fol- 
lowing actions: 


If the distribution is using MU_IDs, then signal DS_RCV_MU_ID_REGISTRY with INSPECT; if its 
value is IN_TRANSIT, then change the entry to COMPLETE. 


Signal QUEUE MGR with RELEASEQ specifying queue(ROUTER_DIRECTOR_QUEUE) to remove the 
in-use mark from the entry on the router-director queue. The entry is then available for proc- 
essing by DS_Router_Director. 


Signal QUEVE_MGR with DEQ specifying queue(ROUTER_DIRECTOR_QUEUE) to remove the distribution 
from the router-director queue. 


Signal QUEVUE_MGR with DEQ specifying queue(MID_MU_RESTART_QUEUE) to discard the copy of the dis- 
tribution on the mid-MU restart queue if mid-MU restart is available. If mid-MU restart is not avail- 
able, processing continues as though QUEUE_MGR returned QUEUE_OK. 


Build a CRMU specifying the MU_/ID state as COMPLETE and signal QUEUVE_MGR with WRITEQ speci- 
fying queue(CONTROL_MU_QUEUE) if MU_IDs are being used. If MU_/Ds are not being used, generating 
the CRMU is optional; if no CRMU is generated, processing continues as though QUEVUE_MGR 
returned QUEUVE_OK. 


Notify operations of the exception condition. , 
Build a CRMU specifying the MU_ID state as COMPLETE and signal QUEVE_MGR with WRITEQ speci- 
fying queue(CONTROL_MU_QUEUE). | 


Signal caller with ENQ SCHED OK to indicate that the distribution was successfully placed on the 
router-director queue and that DS_Router_Director was scheduled. 


Notify operations of the exception condition. 
Signal caller with ENQ_SCHED_OK_DEALLOCATE to indicate that the distribution was successfully 

placed on the router-director queue, that DS_Router_Director was scheduled and that a subsequent 
system error has occurred that should cause the conversation to be aborted. 
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DS_RCV_CQMU_HANDLER 


Function: This finite-state machine describes the functional processing for DS_Receive receiving a CQMU 
from its partner DSU. In state 2, the instance number is checked. If it is too low, the CQMU is 
discarded with no further action. If the instance number is acceptable, the MU_ID state is 
inspected and used to generate a CRMU. MU_/Ds lower than the lowest directory entry are 
considered NOT_RECEIVED, and those higher than the highest directory entry are considered 
PURGED. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS Receive finite-state machines or procedures: 


— from “DS RCV_RECEIVING” on page 237 
— START 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS_RCV_MU_ID_REGISTRY” on page 280 
— NOT_RECEIVED 
— IN TRANSIT 
— SUSPENDED 
— TERMINATED 
— COMPLETE 
— PURGED 
— INSTANCE _NUM_HIGH 
— INSTANCE_NUM_ EQUAL 
— INSTANCE_NUM_LOW 
— MU_ID_AGED_OUT 
— MU_ID_UNINITIALIZED 
— MU_ID_NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE _MGR” on page 357 
— QUEUVE_OK 
— QUEUE NOT_OK 

— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
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Signal DS_RCV_MU_ID_REGISTRY with INSTANCE_NUMBER to compare the CQMU’s instance 
number with the registry’s instance number. The CQMU’s instance number is acceptable if it is 
greater than or equal to the registry’s value. If the CQMU’s instance number is less than the regis- 
try’s, INSTANCE _NUM_LOW is returned (and the CQMU will be discarded). If the CQMU’s instance 
number is greater than the registry’s instance number, the registry’s number is updated to be equal 
to the CQMU. 


Signal DS_RCV_MU_!D_REGISTRY with INSPECT. 
Signal the caller with MU_OK. 
Signal the caller with MU_NOT_OK. 


Build a CRMU and signal QUEUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). 


Build a CRMU and signal QU EUE MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). The 
CRMU specifies that the designated MU_/D state is PURGED. 


Build a CRMU and signal QUEVUE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). The 
CRMU specifies that the designated MU_/D state is NOT_RECEIVED. 


Signal SERVER_MGR with QUERY_LAST_BYTE_RCVD to get the correct byte number for the CRMU. 
If the DTIMU was not suspended in the server object, processing continues as though OBJECT_OK 
was returned. 


Build a CRMU and signal QUEVE_MGR with WRITEQ specifying queue(CONTROL_MU_QUEUE). The 
CRMU specifies that the designated MU_ID state is TERMINATED. 
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DS _RCV_SEMU_HANDLER 


Function: 


This finite-state machine describes the functional processing for DS_Receive receiving a SEMU 
from its partner DSU. In state 2, the instance number and the presence of an MU_ID are 
checked. SEMUs with instance numbers lower than the instance number of the MU_ID registry 
are considered tardy and simply discarded. A SEMU without an MU_/D is logged, and no other 
action is taken. In state 3, the MU_ID state from the registry is inspected, and the appropriate 
exception actions initiated (states 4, 5, 6 and 7). If the MU_ID state is NOT_RECEIVED, the SEMU is 
informing DS_Receive that the partner will never use that MU_JD, and the MU_ID state is 
changed to TERMINATED. For SUSPENDED MU_/Ds, the exception code is examined (state 4) to 
determine if the sender’s exception is retriable or not. If not, the distribution is discarded and 
the MU_ID state changed to TERMINATED. A CRMU reporting the MU_ID state is generated as the 
last exception action. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS _RCV_RECEIVING” on page 237 
— START 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS RCV_DISCARD_DIST” on page 276 
— DIST_DISCARDED 
— DISCARD_FAILED 
— from “DS_RCV_MU_ID_REGISTRY” on page 280 
— NOT_RECEIVED 
— IN_TRANSIT 
— SUSPENDED 
— TERMINATED 
— COMPLETE 
— PURGED 
— INSTANCE_NUM_HIGH 
— INSTANCE_NUM_EQUAL 
— INSTANCE_NUM_LOW 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 


¢ Signals from machines providing common services: 


— from “QUEUE_MGR” on page 357 
— QUEUE OK 
— QUEUE _NOT_OK 
— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
— from “UPM_EXCEPT_RECOVERY_ACTION” on page 285 
— NOT_RETRIABLE 
— RETRIABLE_WITH_MID_MU 
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Signal DS_RCV_MU_ID_REGISTRY with INSTANCE_NUMBER to compare the SEMU’s instance 
number with the registry’s instance number. The SEMU’s instance number is acceptable if it is 
greater than or equal to the registry’s value. If the SEMU’s instance number is less than the regis- 
try’s, INSTANCE _NUM_LOW is returned. If the SEMU’s instance number is greater than the regis- 
try’s instance number, the registry is updated. If the SEMU contains no MU_!ID, processing 
continues with the NO_MU_ID_IN_MU signal. | 


Build a CRMU specifying the MU_/D’s state and signal QUEUE_MANAGER with WRITEQ specifying 
queue(CONTROL_MU_QUEUE). 


Signal UPM_EXCEPT_RECOVERY_ACTION with the error code. 


h Signal DS_RCV_DISCARD_DIST with START. | 


. 
— -— es 
s iJ 


Signal SERVER_MGR with QUERY_LAST_BYTE_RCVD 
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DS _RCV_PRMU_HANDLER 


Function: This finite-state machine describes the functional processing for DS_Receive receiving a PRMU 
from its partner DSU. If the MU_ID state in the registry is SUSPENDED, TERMINATED Or COMPLETED, 
it is changed to PURGED as a result of receiving the PRMU. If the MU_/ID state was SUSPENDED 
prior to receiving the PRMU, the server object is deleted, and any other resources dedicated to 
the distribution (e.g. control blocks and mid-MU restart queue entries) may be reclaimed as 
part of the PRMU processing. 


If the MU_ID state was NOT_RECEIVED or IN_TRANSIT prior to receiving the PRMU, the MU_/D state 


is not changed and the PRMU ignored. If the MU_ID state was already PURGED when the PRMU 
was received, no actions are taken. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS_RCV_RECEIVING” on page 237 
— START 


¢ Signals from lower-level DS_Receive finite-state machines: 


— from “DS _RCV_DISCARD_DIST” on page 276 
— DIST_DISCARDED 7 
— DISCARD_FAILED 
— from “DS _RCV_MU_ID_REGISTRY” on page 280 
— SUSPENDED 
— TERMINATED 
— COMPLETE 
— PURGED 
— MU_ID_AGED_OUT 
— MU_ID_OP_OK 
— MU_ID_OP_NOT_OK 
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Signal DS_RCV_MU_ID_REGISTRY with INSPECT. 


Signal DS_RCV_DISCARD_DIST with START. 


Signal DS_RCV_MU_ID_REGISTRY with PURGE. | 
Signal the caller with MU_OK. 
Signal the caller with MU_NOT_OK. 


Notify operations of the exception condition (that is, the unsolicited PRMU). 
Signal the caller with MU_OK. 
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DS _RCV_SUSP_DIST 


This finite-state machine suspends a distribution which has been partially received. Processing 
of the distribution may be resumed later, possibly by a different instance of DS_Receive. The 
mid-MU restart queue entry is released (so that it may be found later by a READQ queue oper- 
ation), and a Terminate_Write server verb is issued, if necessary. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines or procedures: 


— from “DS_RCV_SUSP_TERM” on page 250 | 
— START 
from “DS_RCV_SEND_ERR_SUSP_TERM_REMU" on page 252 
— START 
from “DS_RCV_REMU_SUSP_TERM” on page 254 
— START | 


¢ Signals from machines providing common services: 
— from “SERVER_MGR” on page 354. 


— OBJECT_OK 
— OBJECT_NOT_OK 
— from “QUEUE_MGR” on page 357 


— QUEUE_OK 
RETRY 
RESET ACTION | TERM WRITE | RELQ FAILED 


— QUEUE _NOT_OK 


START 


QUEUE NOT OK 
OBJECT OK 
OBJECT NOT OK 


Signal SERVER_MGR with TERMINATE_WRITE specifying type(SuSPEND) to preserve the partially- 
received server object, if appropriate. If this distribution does not have a server object, processing 
continues with the QUEUE_OK signal. : 


Signal caller with DIST_SUSPENDED. 
Signal caller with SUSPEND_FAILED. | | | 
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DS_RCV_DISCARD_DIST 


Function: 


Note: 


This finite-state machine describes the functional processing for deleting a partially-received 
distribution. It is called after an exception has been detected during the distribution’s transfer 
from partner DSU to DS_Receive, and after DS_Receive has determined that restarting the 
transmission with a DCMU is not possible. 


This FSM assumes that the general server is being used to store the server object, and that a 
later auxiliary operation will copy the server object from the general server to the specific 
server, if necessary. If, instead, DS_Receive directly stores the server object into the specific 
server, then DS_Receive signals the server manager with either BACKOUT (if Terminate_Write 
has already been issued) or with TERMINATE_WRITE specifying ABort. DS_Receive then 
queues for the destination agent any specific server report that was returned from server 
manager, and signals server manager with DECREMENT_OBJECT_LOCK. 


This FSM gets control from one of the following: 
° Signals from higher-level DS_Receive finite-state machines or procedures: 
— from “DS _RCV_RECEIVE_DMU_NO_MU_ID” on page 259 


— START 

— from “DS _RCV_SUSP_TERM” on page 250 
— START 

— from “DS_RCV_SEND_ERR_SUSP_TERM_REMU” on page 252 
— START 

— from “DS_RCV_REMU_SUSP_TERM” on page 254 
— START 

— from “DS _RCV_SEMU_HANDLER” on page 269 
— START 

— from “DS_RCV_PRMU_HANDLER” on page 272 
— START 


¢ Signals from machines providing common services: 


— from “QUEUE MGR” on page 357 
— QUEUE OK 
— QUEUE _NOT_OK 

— from “SERVER_MGR” on page 354 
— OBJECT_OK 
— OBJECT_NOT_OK 
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lf appropriate, signal SERVER_MGR with TERMINATE_WRITE terminating restartability of the server 
object. 

If a Terminate_Write specifying SUSPEND has been issued previously, then signal SERVER_MGR with 
TERMINATE_RESTARTABILITY, if appropriate. 

If no Initiate_Write has opened the server object or no server object exists for this distribution, 
SERVER_MGR returns OBJECT_OK. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count on the server 
object. If no server object exists, OBJECT_OK is returned. 


Signal QUEVE_MGR with DEQ specifying queue(MiID_MU_RESTART_QUEUE) to remove the partial distrib- 
ution. If mid-MU restart capability is not being used for this distribution, QUEUE_OK is returned. 


fd | Signal caller with DIST_DISCARDED. 


Notify operations of the exception condition. 
Signal caller with DISCARD FAILED. 
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DS_RCV_SEND_CONVERSATION_MGR 


Function: This finite-state machine describes the functional processing for sending a buffer to LU 6.2 
presentation services using the the Send_Data verb. 


This FSM gets control from one of the following: 
¢ Signals from higher-level finite-state machines: 


— from “DS RCV_SENDING” on page 234 
— SEND BUFFER 


Signals from LU 6.2 presentation services: 


ALLOCATION_ERROR 
DEALLOCATE_ABEND 

PROG ERROR 

SVC_ERROR 
RESOURCE_FAILURE 

OK 
OK_AND_REQUEST_TO_SEND 


RESET 


RESOURCE FAILURE 
PROG ERROR 


ALLOCATION ERROR 
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SEND DATA 


Output 
|Code 
Signal LU 6.2 presentation services with SEND_DATA to send the encoded information to the partner 
DSU. 


Signal caller with OK to indicate that the LU 6.2 request was completed successfully. 


Signal caller with CONVERSATION_FAILURE to indicate that some error has occurred on the conver- 
sation between DS_ Send and DS _ Receive. 


Signal caller with PROG_ERROR to indicate that the partner DSU has signalled that an error has 
occurred 

Signal caller with PROTOCOL_ERROR to indicate that an error in the protocols has occurred 
between DS_ Send and DS_Receive 
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DS_RCV_MU_ID_REGISTRY 
This FSM manages DS _Receive’s MU_ID registry for a single connection. Its 
inputs and actions are listed below. All inputs except INSPECT and 
INSTANCE NUMBER return either MU_ID_OP_OK or MU_ID_OP_NOT_OK. 


e IN_TRANSIT 

This input sets the MU_ID state to IN_TRANSIT. 
¢ SUSPENDED 

This input sets the MU_ID state to SUSPENDED. 
¢ TERMINATED 

This input sets the MU_ID state to TERMINATED. 
¢ COMPLETED 

This input sets the MU_/D state to COMPLETED. 
e PURGED 

This input sets the MU_ID state to PURGED. 
e INSPECT 


This input returns the MU_ID state of the designated MU_ID (NOT_RECEIVED, 
SUSPENDED, TERMINATED, COMPLETED, Or PURGED) or MU_ID_OP_NOT_OK, indi- 
cating an error in accessing the MU_ID registry. 


e INSTANCE NUMBER 


Compares a just-received instance number with that stored in the MU_ID 
registry. If the just-received number is less than the registry’s value, 
INSTANCE NUMBER_LOW is returned. If the values are equal, 

INSTANCE NUMBER_EQUAL is returned. If the just-received number is 
greater than the registry’s value, INSTANCE NUMBER_HIGH is returned, 
and the registry’s instance number is replaced by the just-received value. If 
an MU_ID registry failure prevents the registry from being accessed or 
updated, MU_ID_OP_NOT_OK is returned. 


PREPARSER 
This procedure inspects the initial LLID to identify the MU type (DTMU, DCMU, 
DRMU, CQMU, PRMU, or SEMU), the MU_ID and instance number (if appro- 
priate). If the initial LL’s ID is unrecognized, UNKNOWN_ MU is returned. CMUs 
are parsed completely (by having the preparser signal PARSER if necessary). If 
an MU_ID or instance number is improperly specified or missing when required, 
or if a CMU contains a format exception, then BAD_MU is returned. 
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FSMs Providing Common Services for FS2 Transport 
These FSMs are utilities used by both DS_Send and DS Receive. They receive 
data from LU 6.2, detect conversation-idle conditions, and manage the server 
protocol boundary and queue interface. 


The procedures in this class are: 
e “RCV_BUFFER_MGR” on page 282 


This FSM issues all LU 6.2 Receive_And Wait verbs used in the DS trans- 
port sublayer. The what_received parameter returned from LU 6.2 is simpli- 
fied to be specific to DS. For example, a what_received value of CONFIRM, 
CONFIRM_SEND, CONFIRM _DEALLOCATE, and SVC_ERROR all represent an invalid 
usage of the LU 6.2 PB by the partner, and so are collapsed to 

PROTOCOL _ERROR before returning to the caller. 


e “IDLE_DETECTOR” on page 284 


This FSM detects the “conversation idle” condition, which indicates that the 
conversation should be deallocated because DS has no traffic to send over 
it. The conversation idle condition exists when the partner sent nothing 
when it was last in LU 6.2 send state, and this DSU has nothing to send 
currently. In such cases, the conversation is deallocated instead of a 
Receive_And Wait being issued. This condition is checked by both 
DS _ Send and DS _Receive. For example, if DS_ Send receives the send indi- 
cation and has nothing to send, it issues a Receive And Wait, giving 
DS_Receive the send indication. If DS Receive has nothing to send, it deal- 
locates. Conversely, if DS_Receive receives the send indication and has 
nothing to send, it issues a Receive _And_ Wait. If DS Send has nothing to 
send, it deallocates. 


e “QUEUE MGR" on page 357 


This procedure is not explicitly specified. It provides a single means for the 
DS FSMs to access the various queues. QUEUE_MGR performs the speci- 
fied operation and returns a success or failure indication. 


e “SERVER_MGR” on page 354 


This procedure is not explicitly specified. It provides a single means for the 
DS FSMs to access the server verbs. The verb, with its associated parame- 
ters are passed to the server and a success or failure indication is 
returned. 


e “UPM_EXCEPT_RECOVERY_ACTION” on page 285 


This procedure is not explicitly specified. It takes as input parameters an 
exception condition and the distribution to which the exception relates, and 
returns a recommended recovery action (such as Not_Retriable, 
Retriable_Without_Mid_MU, Retriable_With_Mid_MU, or 

Retriable Retry_Exhausted). 
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RCV_BUFFER_MGR 


Function: 


This finite-state machine describes the functional processing to control receiving the data from 
the partner DSU via LU 6.2. In state 1, a Receive_And_Wait LU 6.2 verb is issued. In state 2, 
the what_received parameter is mapped into a DS-specific return code for the partner. For 
example, if what_received is CONFIRM, CONFIRM_SEND, CONFIRM_DEALLOCATE, OF SVC_ERROR, the 
partner has violated DS’s use of the LU 6.2 basic conversation PB, and PROTOCOL_ERROR is 
returned to the caller. 


Deallocate ABEND causes a CONVERSATION_FAILURE to be returned to the caller because, for 
whatever reason, no conversation exists to transmit information to or receive information from 
the partner. 


This FSM gets control from one of the following: 


Signals from higher-level finite-state machines: 


from “DS_SEND_RECEIVING” on page 190 

— RECEIVE_BUFFER 

from “DS _RCV_RECEIVING” on page 237 

— RECEIVE_BUFFER 

from “DS RCV_RECEIVE_DMU_NO_MU_ID” on page 259 
— RECEIVE_BUFFER 

from “DS _RCV_RECEIVE_DMU” on page 240 

— RECEIVE BUFFER 


Signals from LU 6.2 presentation services: 


RCV_AND_WAIT_DATA_COMPLETE 
RCV_AND_WAIT_DATA_INCOMPLETE 
RCV_AND_WAIT_LL_ TRUNCATED 
RCV_AND WAIT _SEND 
RCV_AND_WAIT_CONFIRM_SEND 
RCV_AND_WAIT_CONFIRM 
RCV_AND_WAIT_CONFIRM_DEALLOCATE 
ALLOCATION_ERROR 
DEALLOCATE_NORMAL 
DEALLOCATE_ABEND 

PROG_ERROR 

SVC_ERROR 

RESOURCE_FAILURE 
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. iil s 


RCV AND WAIT DATA INCOMPLETE i ee See 


RCV AND WAIT LL TRUNCATED 
RCV AND WAIT SEND 
RCV AND WAIT CONFIRM SEND 
RCV AND WAIT CONFIRM 
ROV AND WAIT CONFIRM DEALLOCATE 
ney = ee —— acres a 
DEALLOCATE NORMAL 
DEALLOCATE ABEND 
PROG ERROR 
SVC ERROR 


RESOURCE FAILURE 


Signal caller with CHANGE DIRECTION. 


Signal caller with CONVERSATION_FAILURE to indicate that an error occurred on the conversation 
between DS_Send and DS_Receive. 


Signal caller with DEALLOCATE_NORMAL. Receiving a DEALLOCATE_NORMAL in all except the 


first buffer of any MU is a protocol error, but is treated as a conversation failure because the con- 
versation resource is no longer available. 


id Signal caller with PROTOCOL_ERROR to indicate that the partner has violated the DS protocols. 


ig Signal caller with PROG_ERROR to indicate that the partner has encountered an error. 


ew 
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IDLE_DETECTOR 


This finite-state machine describes the functional processing for detecting that a conversation 
is idle and should be deallocated. An idie condition exists when the partner DSU sent nothing 
when it last had the send indication, and the local DSU has nothing to send. Either DS_Send or 
DS_ Receive may deallocate the conversation. 


This FSM gets control from one of the following: 


¢ Signals from higher-level finite-state machines or procedures: 


— from “DS_SEND_MANAGER?” on page 154 
— CHANGE_ DIRECTION 
from “DS_SEND_BUILD_SEND_DMU” on page 163 
— SOMETHING_SENT 
from “DS_SEND_SEND_DMU_NO_MU_ID” on page 181 
— SOMETHING_SENT 
from “DS_SEND_SEND_CONTROL_MU” on page 188 
— SOMETHING _SENT 
from “DS_SEND_RECEIVING” on page 190 
— SOMETHING_RECEIVED 
from “DS_RCV_MANAGER" on page 232 
— CHANGE_ DIRECTION 
from “DS _RCV_SENDING” on page 234 
— SOMETHING _SENT 
from “DS _RCV_RECEIVING” on page 237 
— SOMETHING_RECEIVED 


SOMETHING SENT 
SOMETHING RECEIVED 


Output | Function 
Code 


Signal caller with CHANGE_DIRECTION. 


lb «| Signal caller with DEALLOCATE_FLUSH. 
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UPM_EXCEPT_RECOVERY_ACTION 


This procedure is not explicitly specified. Its input parameters include an 
exception condition, the SENDER_RETRY_ACTION from the REMU (if signalled 
from DS_Send) and the distribution to which the exception relates. The excep- 
tion itself is classified as “retriable” or “not retriable” (see “Characteristics of 
Exception Conditions” on page 407). If the exception is retriable, the dis- 
tribution’s retry count may or may not be exhausted. If the exception is 
retriable and the retry count has not been exhausted, DS_Send or DS_Receive 
may or may not be able to restart transmitting the distribution with a DCMU. 
This procedure’s return codes are: 


e NOT_RETRIABLE 


The exception is not retriable. In this case, questions of retry counts and 
restarting with a DCMU are irrelevant. The distribution will not be retried, 
but will be terminated (and a DRMU generated, as appropriate). The MU_ID 
will be purged. 


¢ RETRIABLE_WITH MID_MU 


The exception is retriable, the retry count has not been exhausted, and the 
distribution can be restarted via a DCMU. 


e RETRIABLE WITHOUT _MID_MU 


The exception is retriable, the retry count has not been exhausted, but the 
distribution cannot be restarted with a DCMU. In this case, the MU_ID will 
be purged, and the distribution will be retransmitted from the beginning 
with a new MU_ID. 


¢ RETRIABLE_RETRY_EXHAUSTED 


The exception is retriable, but DS_Send’s retry count for this distribution 
has been exhausted. The distribution will not be retried, but will be termi- 
nated (and a DRMU generated, as appropriate). The MU_ID will be purged. 


Distribution Transport Sublayer—Format Set 1 


DS Send FSMs 


DS Send Overview 


DS_Send is shown here as a set of machines that send FS1 DMUs across an LU 
6.2 conversation to an instance of DS_Receive in an adjacent DSU. The exe- 
cution of these machines results in all the DS FS1 protocols for sending DMUs, 
and all the exception protocols for both sender- and receiver-detected 
exceptions. There are several points to note about these protocols. 


¢ Deallocate type(SYNC_LEVEL) is not issued by the formal model, although 
product implementations may elect to do so. 


e The number of Send_Data verbs issued to LU 6.2 in order to transmit a DS 
MU is an implementation optimization choice. It will be dependent on the 
buffer sizes at the nodes at which the DSU resides. 
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e Each machine that issues verbs to LU 6.2 is listed below, with a summary of 
its function. All DS implementations follow the protocols embodied in these 
machines. 


— FSM_SEND_MGR—controls allocation and deallocation of the conversa- 
tion resource for DS_Send. It handles an Attach from DS Receive as 
well as sending an Attach to DS_Receive. It also issues the proper 
deallocation type for all situations, both exception and normal. 


— DS_SEND_CONVERSATION MGR—Controls the normal sending of data 
and the Confirm request. It reports exception conditions to higher-level 
FSMs for proper exception handling protocols and conversation deallo- 
cation. 


— FSM_SEMU_ENCODE—Controls the exception protocols for exceptions 
detected by the local conversation partner (DS_Send), and handles any 
further exceptions that may occur during this processing. 


— FSM _REMU_DECODE—Controls the receiving, via LU 6.2, of the 
Receiver Exception Message Unit (REMU) from the remote conversation 
partner, and handles any further exceptions that may occur during this 
processing. 


Although the structure of these machines is peculiar to the formal model, all DS 
implementations generate these protocols. In addition, all DS implementations 
generate an asynchronous report in the case of nonretriable exceptions. 


Program Structure 
These FSMs are structured so that a manager machine (FSM_SEND_MGR) both 
allocates and deallocates the conversation. Once the conversation is started, 
machines lower in the hierarchy sequence the functions necessary to send a 
distribution coded in DMU format. The manager machine receives reports on 
the progress of the transmission. If exceptions are detected, the manager 
machine causes one of two exception protocol machines to start. The excep- 
tion protocol machines report on the progress of the exception information 
being transferred. If an exception occurs during an exception protocol, the 
manager machine takes appropriate action. 


As each piece of the DMU is encoded, FSM_SEND_CONVERSATION_MGR is 
signalled to issue the appropriate LU 6.2 verb to send the data across the con- 
versation. The manager machine and the exception protocol machines issue 
their own LU 6.2 verbs. The conversation state is kept in LU 6.2 presentation 
services. The state of the protocol is kept by a combination of machines and 
states in DS. 
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FSM_SCHED_MGR LU 6.2 


START_TRANSACTION ATTACH when allocated 
by DS Receive 


FSM_OPERATIONS MGR 


FSM_SEND_MGR 


FSM_DIST_ENCODE_ 
CONTROL 


SERVER_MGR 


* 


FSM_SEMU_ENCODE FSM_REMU_ 


DECODE 


BUILDER 


* 


SERVER_ 
MGR 


* 


LU 6.2 Presentation Services 


* indicates those finite-state machines not formally specified. 


For more details regarding the finite-state machines, see: 


"FSM_SEMU ENCODE" on page 304 
LU 6.2 presentation services 
"FSM_SCHED_MGR" on page 351 
"PARSER" on page 359 
"SERVER_MGR" on page 354 
"BUILDER" on page 359 
"QUEUE_MGR" on page 357 


"FSM_SEND_MGR" on page 288 

"FSM_REMU DECODE" on page 366 
"FSM_OPERATIONS MGR" on page 342 
"FSM_SRVR_OBJECT_READ" on page 366 

"FSM _DIST_ENCODE CONTROL" on page 296 
"FSM_ SEND CONVERSATION _MGR" on page 362 


Figure 47. DS_Send FSM Hierarchy 
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FSM_SEND_MGR 


This machine sequences the operations required to send DMUs from DS_Send 
at one DSU on an LU 6.2 conversation to DS_Receive at another DSU. The 
request for this function is from DS_Router_Director, the local operator, or 
DS_Receive. 


The sequences of functions controlled by FSM_SEND_MGR are: 


e Allocation of the conversation to DS_Receive, or receiving the indication to 
send if DS_ Send is attached by DS_Receive. 


¢ Accessing the next available queue entry from the next-DSU queues in pri- 
ority order. 


e Encoding the distribution in DMU format. 

e Sending the DMU on the LU 6.2 conversation using DS protocols. 

e Taking the entry from the next-DSU queue when DS_Receive has accepted 
responsibility for it. 

e Decrementing the DS lock count placed on the server object by presenta- 
tion services or DS_Receive. 


¢ Deallocation of the conversation when the queues are empty or an excep- 
tion has occurred. 


Processing stops when any of the following occurs: 


e The conversation cannot be allocated, or DS_Send does not receive the 
indication to send, if DS_Receive performs the allocation. 


e An exception occurs while the queue is being accessed. 
e The queues are held by another instance of DS_Send. 
e DS Receive encounters an exception and notifies DS_Send. 


e DS Send encounters an exception while building the DMU or accessing the 
server object. 


e An exception on the conversation occurs. 


For exceptions detected by DS_Send, FSM_SEND_MGR signals machines to 
pass exception information to DS Receive. For exceptions detected by 

DS_ Receive, FSM _SEND_MGR signals machines to receive exception informa- 
tion from DS_Receive. For all exceptions, FSM_SEND_MGR performs the 
appropriate deallocation, and signals FSM_OPERATIONS_MGR for logging, 
operator messages, setting of queue control, and generating asynchronous 
report, if appropriate. 


The FSM_SEND_MGR has three key states that determine DS actions in excep- 
tion situations detected by the sending side of the conversation. In the fol- 
lowing text, “local conversation partner” refers to the DSU sending the DMU, 
and “remote conversation partner” refers to the DSU receiving the DMU. 


FSM_SEND_MGR—ENC Sfate: In this state, the local conversation manager 
waits for a report on the encoding and sending of the DMU. The signals 
received in this state have the following meanings: 
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e DMU ABORT—No data has been sent so far on the conversation. An 
exception was detected on the first call to the builder. This is neither an 
exception in the distribution, nor an exception in the conversation. DS 
issues an LU 6.2 Deallocate type(FLUSH) verb to terminate the conversation. 


e SEND SIDE EXCEPT—Another machine in the hierarchy detected an excep- 
tion during the encoding of the DMU or the reading of the server object. 
This is a purely local exception, not a conversation exception. In this case, 
FSM_SEND_MGR signals another machine, FSM_SEMU_ENCODE, to handle 
the DS exception protocol. This includes informing the conversation partner 
of the exception and transmitting a SEMU. 


e RCV_SIDE_EXCEPT—LU 6.2 PS returned a PROG_ERROR_PURGING on a verb 
issued by the local conversation partner, indicating that the remote conver- 
sation partner has detected an exception. FSM _SEND_MGR signals another 
machine, FSM_REMU_DECODE, to handle the exception protocol, which 
includes receiving an REMU from the remote conversation partner. 


¢ CONVERSATION _FAILURE—LU 6.2 PS returns one of the following return 
codes on a verb that DS issued: 


— ALLOCATION_ERROR—A conversation could not be allocated, but DS has 
begun to pass records to LU 6.2 PS. 


— DEALLOCATE_ABEND_PROG—The remote conversation partner has detected 
an exception preventing further communication, and has issued a Deal- 
locate type(ABEND_ PROG), or the remote LU has signalled a remote 
program abend condition. 


— RESOURCE_FAILURE—The session has been lost. 


In each of these cases, the conversation no longer exists, and DS issues a 
Deallocate type(LOCAL) to terminate the local side of the conversation. 


FSM_SEND_MGR-—SND_EXPT State: In this state, FSM_SEND_MGR is waiting 
for a report on the progress of the exception protocol following the detection of 
an exception at the local DSU. 


e SEND SIDE _ EXCEPT— FSM_SEMU_ ENCODE has encountered an exception 
in encoding the SEMU. The exception protocol cannot be completed, and 
DS terminates the conversation by issuing Deallocate type(ABEND PROG). 


e RCV_SIDE_EXCEPT—The local and remote conversation partners have both 
issued Send Error verbs. The remote conversation partner purges every- 
thing received from the local conversation partner, including the FMH-7 
from the local’s Send_Error verb. The result is that the remote conversa- 
tion partner is in send state when the exchange is complete. LU 6.2 PS 
returned a PROG_ERROR_PURGING return code in reply to the Send Error or in 
reply to the Send_Data verb that the local conversation partner issued. 
FSM_SEND_MGR signals another machine, FSM_REMU_DECODE, to handle 
the exception protocol, which includes receiving an REMU from the remote 
conversation partner. 


¢ CONVERSATION _FAILURE—LU 6.2 PS returns one of the following return 
codes on a verb that DS issued: 
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— ALLOCATION_ERROR—A conversation could not be allocated, but DS has 
begun to pass records to LU 6.2 PS. 


— DEALLOCATE_ABEND_PROG—The remote conversation partner has detected 
an exception preventing further communication, and has issued a Deal- 
locate type(ABEND_PROG), or the remote LU has signalled a remote 
program abend condition. 


— RESOURCE_FAILURE—The session has been lost. 


In each of these cases, the conversation no longer exists, and DS issues a 
Deallocate type(LOCAL) to terminate the local side of the conversation. 


e ERP_COMPLETE— FSM_SEMU_ENCODE has completed the exception pro- 
tocol successfully. FSM_SEND_MGR closes the conversation by issuing 
Deallocate type(FLUSH). 


FSM_SEND_MGR—RCV_EXPT State: In this state, the FSM _SEND_MGR is 
waiting for a report on the progress of the exception protocol following the 
detection of an exception at the remote conversation partner. 


e SEND_SIDE_EXCEPT— FSM_REMU_DECODE has encountered an exception 
in parsing the REMU. The rest of the REMU is ignored, and the remote con- 
versation partner has terminated the conversation normally. The 
FSM_SEND_MGR issues a Deallocate type(LOCAL). 


e PROTOCOL ERROR—LU 6.2 PS returned a PROG_ERROR_TRUNC, 
PROG_ERROR_NO_TRUNC, what_received(SEND), or what_received(CONFIRM), to a 
Receive_And_Wait verb that FSM_REMU_DECODE has issued. These return 
codes indicate that the partner DSU has issued a sequence of LU 6.2 verbs 
that, although legitimate under LU 6.2 rules of usage, is not legitimate under 
DS rules of usage. 


In addition, after the REMU has been received completely, 
what_received(DATA) becomes an improper DS usage of LU 6.2. The local 
conversation partner must assume that reliable communication cannot con- 
tinue with the remote conversation partner. The FSM_SEND_MGR issues a 
Deallocate type(ABEND_PROG) to terminate the conversation abnormally. 


e CONVERSATION _FAILURE—LU 6.2 PS returns one of the following return 
codes on a verb that DS issued: 


— DEALLOCATE_ABEND_PROG—The remote conversation partner has detected 
an exception preventing further communication, and has issued a Deal- 
locate type(ABEND_PROG), or the remote LU has signalled a remote 
program abend condition. 


— RESOURCE_FAILURE—The session has been lost. 


In each of these cases, the conversation no longer exists, and DS issues a 
Deallocate type(LOCAL) to terminate the local side of the conversation. If LU 
6.2 PS returns a Deallocate NORMAL before the REMU is received com- 
pletely, it is an improper DS usage of LU 6.2, but because the conversation 
no longer exists, FSM_REMU_DECODE signals a CONVERSATION_FAILURE 
to the FSM_SEND_MGR. This exception is still reported and logged as an 
improper DS usage of LU 6.2. 
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e ERP_COMPLETE— FSM_REMU_DECODE has completed the exception pro- 
tocol successfully. FSM SEND MGR closes the conversation by issuing 
Deallocate type(LOCAL). 
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Function: This finite-state machine describes the functional processing for the send manager of DS_Send. 
For a further description, see “FSM_SEND_ MGR” on page 288. 


This FSM gets control from one of the following: 


Signals from finite-state machines providing common services: 


— START_TRANSACTION from FSM SCHED _MGR 
— OPERATIONS COMPLETE from FSM OPERATIONS MGR 
— OBJECT_OK from SERVER_MGR 

— OBJECT NOT_OK from SERVER_MGR 


Signals from LU 6.2 presentation services: 


— ATTACH from LU 6.2 when DS_Receive issues Allocate 

— OK from Allocate, Deallocate FLUSH, Deallocate LocaL, Deallocate ABEND 
—- ALLOC_PARAM_ERROR from Allocate 

— ALLOCATION_ERROR from Allocate, Receive_And_Wait 

— RCV_AND_WAIT_SEND from Receive_And_Wait 

— RCV_AND_WAIT_CONFIRM from Receive_And_Wait 

— RCV_AND_WAIT_CONFIRM_DEALLOCATE from Receive_And_Wait 
— RCV_AND_WAIT_DATA_COMPLETE from Receive_And_Wait 

— RCV_AND_WAIT_DATA_INCOMPLETE from Receive_And_Wait 

— RCV_AND_WAIT_LL_TRUNCATED from Receive_And_Wait 

— DEALLOCATE_NORMAL from Receive_And_Wait 

— DEALLOCATE_ABEND from Receive_And_Wait 

— PROG_ERROR from Receive_And_Wait 

— RESOURCE_FAILURE from Receive_And_Wait 


Signals from lower-level DS_Send machines: 


— QUEUE_EMPTY from QUEUE_MGR 
— QUEUE _OK from QUEUE_MGR 
— QUEUE _NOT_OK from QUEVE_MGR 
— DMU_COMPLETE from FSM_DIST_ENCODE_CONTROL 
— DMU_ABORT from FSM_DIST_ENCODE_CONTROL 
— SEND SIDE EXCEPT 
— from FSM_DIST_ENCODE_CONTROL 
— from FSM SEMU_ENCODE 
— from FSM_REMU_DECODE 
— RCV_SIDE_EXCEPT from FSM_DIST_ENCODE_CONTROL, FSM_SEMU_ENCODE 
— PROTOCOL_ERROR from FSM_SEMU_ENCODE, FSM_REMU_DECODE 
— CONVERSATION FAILURE 
— from FSM_DIST_ENCODE_CONTROL 
— from FSM SEMU_ENCODE 
— from FSM_REMU_DECODE 
— ERP_COMPLETE from FSM_SEMU_ENCODE, FSM_REMU_DECODE 
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Output 
Code 
Signal LU 6.2 presentation services with ALLOCATE to establish the conversation with DS_ Receive. 


Signal LU 6.2 presentation services with GET_ATTRIBUTES and RECEIVE_AND WAIT to determine 
the LU name, mode name, and to receive the indication from the partner to send. 


Signal QUEVE_MGR with READO to retrieve the appropriate next-DSU queue entry to be selected 
based on priority of traffic. 


Signal FSM_OPERATIONS_MGR with LOG_MESSAGE_EXCEPT for logging and operator messages. 
No report is requested because no MU was involved or DS_Receive had already accepted responsi- 
bility for the distribution. 


Signal LU 6.2 Bicsentiauen services with DEALLOCATE _ LOCAL to deallocate the conversation 
locally. 

Signal LU 6.2 presentation services with DEALLOCATE_ABEND to deallocate the conversation abnor- 
mally. 


Signal FSM_OPERATIONS_MGR with SEND_MU_EXCEPT to log, generate report if appropriate, set 
queue control, and for operator messages. 


Signal LU 6.2 presentation services with DEALLOCATE specifying FLUSH to signal the partner that no 
more DMUs will be sent. 

Signal FSM_DIST_ENCODE_CONTROL with ENCODE to control the building and the sending of the 
DMU to DS_Receive. 

Signal FSM_SEMU_ENCODE with ENCODE_SEMU to control the exception protocols for an exception 
encountered by DS_Send. 

Signal FSM_REMU_DECODE with DECODE_REMU to control the receipt of the REMU that resulted 
from an exception encountered by DS_ Receive. 


Signal QUEVE_MGR with DEQ to remove the entry from the next-DSU queue following suecesetul 
processing of the entry. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count on the server 
object. DS_Receive has accepted responsibility for the distribution. If no object exists, 
SERVER_MGR returns OBJECT_OK. 
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FSM_DIST_ENCODE_CONTROL 
Controls the building of the distribution in DMU format, and the sending of the 
DMU on the conversation to DS_Receive. The request for this function is from 
FSM_SEND_MGR. 


This machine signals machines to build and send the DMU. Upon successful 
completion of building and sending the DMU, this machine signals the 
FSM_SEND_CONVERSATION_MGR to send the Confirm to DS_Receive. When 
DS_Receive sends Confirmed, this machine notifies FSM_SEND_ MGR that 
responsibility for the distribution has been accepted by DS _ Receive. Exceptions 
in encoding are reported by the builder. If the builder returns BUILD_NOT_OK 
on the first call, this machine signals DMU_ABORT to “FSM_SEND_MGR” on 
page 288. If the builder returns BUILD _NOT_OK on any subsequent call, this 
machine signals SEND_SIDE_EXCEPT to FSM_SEND_MGR. Exceptions in 

DS_ Receive receiving the DMU result in RCV_SIDE_EXCEPT to 
FSM_SEND_MGR, and exceptions on the conversation result in 
CONVERSATION FAILURE to FSM_SEND_MGR. This machine passes the avail- 
able exception information to the signalling machine. For a further description 
of these exceptions, refer to “FSM_SEND_MGR—ENC State” on page 288. 
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This finite-state machine describes the functional processing for controlling the encoding and 
sending of the DMU. Fora further description, see “FSM_DIST_ENCODE_CONTROL” on 
page 296. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines: 


~— ENCODE from FSM_SEND_MGR 
Signals from lower-level DS_Send finite-state machines: 


OBJECT-OK from FSM_SRVR_OBJECT_READ 

NO_OBJECT_EXISTS from FSM_SRVR_OBJECT_READ 
OBJECT_EOD from FSM_SRVR_OBJECT_READ 

OBJECT _NOT_OK from FSM_SRVR_OBJECT_READ 

OK from FSM_SEND_CONVERSATION_MGR 

RCV_SIDE_EXCEPT from FSM_SEND_CONVERSATION_MGR 
CONVERSATION FAILURE from FSM_SEND_CONVERSATION_MGR 


Signals from BUILDER 


— BUILD _OK | 
— BUILD OK_GET_OBJECT 
— BUILD COMPLETE 

— BUILD NOT_OK 
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Signal BUILDER with BUILD to build the DMU information 


Signal FSM_SEND_CONVERSATION_MGR with SEND BUFFER to send the DMU information to LU 6.2 
PS. 

Signal FSM_SEND_MGR with DMU_ABORT to indicate that an exception has occurred in building the 
DMU. No portion of the DMU has been sent; therefore, normal send side exception processing does 
not take place. | 


Signal FSM_SEND_MGR with SEND_SIDE_EXCEPT to indicate that an exception has occurred in the 
encoding process and that the sender exception protocols should be followed. 


Signal FSM_SRVR_OBJECT_READ with CLEANUP_OBJECT to terminate any access to the object, if 
one exists. 


Signal FSM_SRVR_OBJECT_READ with READ OBJECT to read the object and perform any initializa- 
tion for reading, if not yet performed. | 


Signal FSM_SEND_CONVERSATION_MGR with END_DMU tec indicate that the Confirm should be sent 
to DS_Receive. 


Signal FSM_SEND MGR with DMU_COMPLETE to indicate that the DMU has been encoded and sent 
to DS_Receive. Also, the Confirm has been sent to DS_Receive and ok to Confirm has been 
received. 


Signal BUILDER with END_OBJECT to indicate that the server has returned Eop and the last segment 
of the object should be built, or if no object exists the length of the data will be 0. 
Signal FSM_SEND_MGR with RCV_SIDE_EXCEPT to indicate that an exception has occurred in 


DS_Receive and that the receiver exception protocols should be followed. 


Signal FSM_SEND_MGR with CONVERSATION_FAILURE to indicate that an exception has occurred in 
the conversation between DS_Send and DS_Receive. 
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FSM_SRVR_OBJECT_READ _ 
This machine controls the reading of the server object. The request for this 
function is from FSM_DIST_ENCODE CONTROL signalling READ_OBJECT or | 
CLEANUP OBJECT, and passing the descriptor of the server object, the origin 
server name, and parameters (if the DSU is the origin DSU). 


For an input signal of READ_OBJECT, this machine issues Read to 
SERVER_MGR. For an input signal of CLEANUP_OBJECT prior to a successful 
Initiate_Read operation, this machine signals OBJECT_OK to the calling 
machine. For any subsequent input signal of CLEANUP_OBJECT, this machine 
issues Terminate_Read to SERVER_MGR and returns OBJECT _NOT_OK. 


Exceptions can occur in accessing the server object. For any exception, if an 
Initiate_Read verb has been issued, then a Terminate_Read verb must be 
issued to close the access path. In case of an exception from the server in 
attempting to close the access path, FSM_SRVR_OBJECT_READ should signal 
FSM_OPERATIONS MGR with MESSAGE_TO_OPERATOR. This machine does 
not show that signal. 


Exceptions in accessing the server object result in an OBJECT_NOT_OK signal 
to FSM_DIST_ENCODE_CONTROL and, in turn, a SEND_SIDE_EXCEPT signal to 
FSM_SEND_MGR. This machine passes the available exception information to 
FSM_DIST_ENCODE_CONTROL. The processing performed for this exception is 
described in “FSM_SEND_MGR—ENC State” on page 288. | 
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Function: This finite-state machine describes the functional processing for reading the server object. 
a further description, see “FSM SRVR_OBJECT_READ” on page 300. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines: 


— READ_OBJECT from FSM_DIST_ENCODE_CONTROL 
— CLEANUP_OBJECT from FSM_DIST_ENCODE_CONTROL 


¢ Signals from machines providing common services: 


OBJECT_OK from SERVER_MGR 
OBJECT _EOD from SERVER_MGR 
OBJECT _NOT_OK from SERVER_MGR 
NO_OBJECT_EXISTS from SERVER_MGR 


= RESET epee TRM READ = 


Signal FSM_DIST_ENCODE_CONTROL with OBJECT_OK to indicate that the portion of the object has 
been read. If no object exists and the signal is CLEANUP_OBJECT, then OBJECT _OK is signalled. 


Signal SERVER_MGR with READ to read a portion of the object, performing any initialization, if nec- 
essary. If no server object exists, then NO_OBJECT_EXISTS is returned. 


a Signal FSM_DIST ENCODE CONTROL with NO_OBJECT_EXISTS to indicate that there is no object to 


Signal FSM_DIST_ENCODE_ CONTROL with OBJECT_NOT_OK to indicate that an exception: has 
occurred during the accessing of the object. 


Signal SERVER_MGR with TERMINATE_READ to terminate any access to the object. 


T Signal FSM_DIST_ENCODE_ CONTROL with OBJECT_EOD to indicate that the object has been read to , 
completion, and access to the object has been terminated. 
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FSM_SEND_CONVERSATION_MGR 
This machine issues the Send_Data and Confirm verbs to LU 6.2 presentation 
services, and classifies the conversation exceptions. The request for the send 
function is from FSM_DIST_ENCODE_CONTROL signalling SEND_BUFFER. The 


request to send Confirm is from FSM_DIST_ENCODE_CONTROL signalling 
END_DMU. | 


Figure 48 classifies the possible exceptions returned from LU 6.2 PS. 


Return Code Reported as Explanation 


ALLOCATION ERROR CONVERSATION FAILURE |Conversation was never allocated. | 
DEALLOCATE ABEND PROG} CONVERSATION FAILURE |DS Receive or the remote LU has terminated the 


conversation abnormally. 
PROG ERROR PURGING RCV_SIDE_ERROR DS_Receive issued a Send_Error verb to signal error. 
RESOURCE FAILURE CONVERSATION FAILURE |Conversation was lost because the session was lost. 


Figure 48. Classification of NOT-OK Return Codes by FSM_SEND_CONVERSATION_MGR. 
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This finite-state machine describes the functional processing for interacting with each encode 
machine for the sending of the DMU to DS_Receive. For a further description, see 
“FSM_SEND_CONVERSATION_MGR” on page 302. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines: 


— SEND BUFFER from FSM_DIST_ENCODE_CONTROL 
— END _DMU from FSM_DIST_ENCODE_CONTROL 


Signals from LU 6.2 presentation services: 


ALLOCATION_ERROR from Send_Data, Confirm 
DEALLOCATE_ABEND from Send_Data, Confirm 
PROG_ERROR from Send_Data, Confirm 
RESOURCE_FAILURE from Send_Data, Confirm 
OK from Send_Data, Confirm 


‘ALLOCATION ERROR» 


DEALLOCATE ABEND | 


PROG ERROR 
RESOURCE FAILURE 


ae LU 6.2 presentation services with SEND_DATA to send the encoded information to the Partner 


Signal LU 6.2 presentation services with CONFIRM to synchronize the processing between DS_Send 
and DS_Receive, following the sending of the DMU. 


Signal FSM_DIST_ENCODE_CONTROL with CONVERSATION_FAILURE to indicate that some excep- 
tion has occurred on the conversation between DS_Send and DS _ Receive. 


Signal FSM_DIST_ENCODE_CONTROL with RCV_SIDE_EXCEPT to indicate that DS_Receive has sig- 
nalled that an exception has occurred on the receive side. 
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FSM_SEMU_ENCODE 
The function of this machine is to indicate to DS_Receive that an exception has 
occurred and the remainder of the DMU is not to follow. This function is 
requested from FSM_SEND_MGR signalling ENCODE,SEMU. The exception 
information required for building the exception code is passed to this machine. 


The DS protocol for this processing is as follows: 


¢ Issue a Send_Error to LU 6.2 presentation services. 

¢ Build a SEMU indicating a forward abort. The SEMU contains the exception 
information. 

¢ Issue a Send_ Data, containing the SEMU, to LU 6.2 presentation services. 


Exceptions can occur in the encoding process, and in sending the SEMU on the 


LU 6.2 conversation. For a further description of these exceptions and the proc- 
essing that results, refer to “FSM_SEND_MGR—SND_EXPT State” on page 289. 
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This finite-state machine describes the functional processing for exception processing in 
DS_Send when the exception occurred on the sending side. For a further description, see 
“FSM_SEMU_ENCODE” on page 304. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines: 
— ENCODE SEMU from FSM_SEND_MGR 


Signals from LU 6.2 presentation services: 


OK from Send_Error, Send_Data 
ALLOCATION_ERROR from Send_Error, Send_Data 
RESOURCE FAILURE from Send_Error, Send_Data 
PROG_ERROR from Send_Error, Send_ Data 
DEALLOCATE ABEND from Send _ Error, Send_Data 


SEND_ERR 
RESET PEND 


ENCODE SEMU — 


ALLOCATION. ERROR | 
DEALLOCATE ABEND 
PROG ERROR 

RESOURCE FAILURE 


Output |Function 
Code 


Signal LU 6.2 presentation services with SEND_ERROR to indicate to the partner that an exception 
has been encountered on the sending side. 


Build the SEMU and signal LU 6. 2 presentation services with SEND_DATA to send the encoded infor- 
mation to the partner DSU. 


ae Signal FSM_SEND_MGR with ERP_COMPLETE to indicate that exception processing has been com- 


pleted and that appropriate deallocation should take place. 
Signal FSM_SEND_MGR with RCV_SIDE_EXCEPT to indicate that while performing exception proc- 


essing for an exception encountered on the sending side, the receiving side has indicated an excep- 
tion. 


Signal FSM_SEND_MGR with CONVERSATION. FAILURE to indicate that an exception occurred on 
the conversation while the exception information was being sent to DS_Receive. 
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FSM_REMU_DECODE | | 
The function of this machine is to receive exception information from 
DS Receive after DS_ Receive has encountered an exception in receiving or 
parsing a DMU. This function is requested from FSM_SEND_MGR signalling 
DECODE_REMU. 


The DS protocol for this exception is as follows: 


e Issue Receive_And_ Wait for the REMU. 
e Parse the REMU containing the exception information. 
e Issue Receive_And_Wait for the indication of Deallocate NORMAL. 


Once FSM_REMU_DECODE receives and parses the REMU, it passes the REMU 
exception fields to FSM_SEND_MGR with the signal ERP_COMPLETE. 


If an exception occurs in parsing the REMU, this machine issues 
Receive_And_Wait verbs until enough data has been received to comprise a 
complete REMU. If the next Receive_And_Wait verb does not return a Deallo- 
cate NORMAL as the return code, then it is treated as an abnormal case and 
logged as an improper DS usage of LU 6.2. Exceptions can occur while the MU 
is being received on the LU 6.2 conversation or in parsing the REMU. Fora 
further description of these exceptions and the processing that results, see 
“FSM_SEND_MGR—RCV_EXPT State” on page 290. 
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This finite-state machine describes the functional processing for exception processing in 
DS_Send when the exception occurred on the receiving side. For a further description, see 
“FSM_REMU_DECODE?” on page 306. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Send finite-state machines: 


— DECODE_REMU from FSM_SEND_MGR 
Signals from PARSER 


= PARSE_NOT_OK—on PARSE _NOT_OK, Receive_And_Wait is issued until enough data 
has been received to comprise a complete REMU. 
~— PARSE_COMPLETE 


Signals from LU 6.2 presentation services: 


RCV_AND_WAIT_SEND 
RCV_AND_WAIT_CONFIRM 
RCV_AND_WAIT_CONFIRM_DEALLOCATE | 
RCV_AND_WAIT_DATA_COMPLETE 
RCV_AND_WAIT_DATA_INCOMPLETE 
RCV_AND_WAIT_LL_ TRUNCATED 
RESOURCE_FAILURE 

PROG_ERROR 

DEALLOCATE_ABEND 
DEALLOCATE_NORMAL 


DEALLOC 
RESET RCV REMU EXPT PEND 


RCV AND WAIT DATA INCOMPLETE 
RCV AND WAIT LL TRUNCATED 


RCV AND WAIT SEND 
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Output | Function 
Code 


Signal LU 6.2 presentation services with RECEIVE_AND_WAIT to receive exception information from 
DS_Receive. 


Signal PARSER with PARSE_REMU to parse the REMU 


Signal FSM_SEND_MGR with PROTOCOL_ERROR to indicate that the proper exception protocols 
were not followed for exception processing 


Signal FSM_SEND_MGR with CONVERSATION _ FAILURE to indicate that exception processing was 
not successfully completed. 

Signal FSM_SEND_MGR with SEND_SIDE_EXCEPT to indicate that an exception occurred in parsing 
the REMU. 


f Signal FSM_SEND_MGR with ERP_COMPLETE to indicate that exception processing has been com- 
pleted, and that appropriate deallocation should take place. 
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DS Receive FSMs 


DS Receive Overview 
DS_ Receive is shown here as a complex of machines whose function it is to 
receive DMUs on an LU 6.2 conversation from an instance of DS_Send in an 
adjacent DSU. These machines execute all the FS1 DS protocols for receiving 
DMUs, and all the protocols for both sender-and receiver-detected exceptions. 
There are several points to note about these protocols. 


e Deallocate type(SYNC_LEVEL) is not issued by the formal model when 
sending, but all receivers can properly handle what_received(CONFIRM) and 
what_received(CONFIRM_DEALLOCATE) as parameters returned on the 
Receive_And_Wait verb. 


¢ The number of Receive_And_Wait verbs issued in order to receive a DS MU 
is an implementation optimization choice. It will depend on the buffer sizes 
at the nodes at which the DSU resides, and on whether fi//(BUFFER) or fill{LL) 
is used by the implementation. 


¢ Each machine that issues verbs to LU 6.2 PS is listed below, with a 
summary of its function. All DS implementations follow the protocols 
embodied in these machines. 


— FSM_RECEIVE MGR—Controls allocation and deallocation of the con- 
versation resource for DS_Receive. It handles an Attach from DS_Send 
as weil as sending an Attach to DS_Send. Some implementations may 
not send an Attach to DS_Send. It also issues the proper deallocation 
type for all situations, both exception and normal. 


— FSM_RCV_CONVERSATION_MGR—Controls the normal receiving of 
data and the Confirmed reply. It reports exception conditions to higher- 
level FSMs for proper exception-handling protocols and conversation 
deallocation. 


— FSM _SEMU_DECODE—Controls the protocols for exceptions detected by 
the remote conversation partner, (DS Send) and handles any further 
exceptions that may occur during this processing. 


— FSM _REMU_ENCODE—Controls the sending, via LU 6.2 PS, of the REMU 
by the local conversation partner, and handles any further exceptions 
that may occur during this processing. 


Although the structure of these machines may be peculiar to the formal model, 
all DS implementations generate these protocols. 


Program Structure 
These machines are structured so that a manager machine 
(FSM_RECEIVE_MGR) both allocates and deallocates the conversation. Once 
the conversation is started, machines lower in the hierarchy sequence the func- 
tions necessary to receive a distribution and parse the DMU. The manager 
machine receives reports on the progress of the transmission. If exceptions 
are detected, the manager machine causes one of two exception protocol 
machines to start. The exception protocol machines report on the progress of 
the exception information being transferred. If an exception occurs during an 
exception protocol, the manager machine takes appropriate action. 
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As each piece of the DMU is decoded, FSM_RCV_CONVERSATION_MGR is sig- 
nalled to issue the appropriate LU 6.2 verb to retrieve the data from the LU. 
The manager machine and the exception protocol machines issue their own LU 
6.2 verbs. The conversation state is kept in LU 6.2 PS. The state of the pro- 
tocol is kept by a combination of machines and states in DS. 
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FSM_SCHED_MGR LU 6.2 
START_TRANSACTION ATTACH when allocated 
by DS_ Send 


FSM_OPERATIONS MGR 


FSM_RECEIVE_MGR 


FSM_DIST_DECODE 
_CONTROL 


FSM_SEMU_ 
DECODE 


FSM_REMU ENCODE — 


PARSER FSM_RCV_ 
ENQ_ 


SCHED 


* 


SERVER SERVER_| FSM. 
MGR MGR SCHED_ 
* * MGR 


LU 6.2 Presentation Services 


* indicates those finite-state machines not formally specified. 


For more details regarding the finite-state machines, see: 


"FSM_RECEIVE_MGR" on page 313 
"FSM_SRVR_OBJECT_WRITE" on page 328 
"FSM_OPERATIONS MGR" on page 342 
"FSM_RCV_CONVERSATION MGR" on page 330 
"FSM_DIST_DECODE_CONTROL" on page 320 
"FSM_RCV_ENQ_SCHED" on page 324 
"FSM_SEMU_DECODE" on page 334 


"FSM _SCHED_MGR" on page 351 
"FSM_REMU_ENCODE" on page 338 
LU 6.2 presentation services 
"PARSER" on page 359 
"SERVER_MGR" on page 354 
"BUILDER" on page 359 
"QUEUE_MGR" on page 357 


Figure 49. Ds_ Receive FSM Hierarchy 
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FSM_RECEIVE_MGR 
Sequences the functions required to receive and accept responsibility for a 
DMU sent from DS_Send over an LU 6.2 conversation to an instance of 
DS _ Receive at another DSU. The request for this function can be from the local 
operator, or from DS_Send issuing an Allocate for DS_Receive. 


The functions controlled by FSM RECEIVE_MGR are: 
e Allocation of the conversation to DS Send, if started locally. 


e Decoding the DMU format of the distribution and scheduling further proc- 
essing. 


e Deallocating the conversation when DS Send signals that there are no 
more DMUs to flow on the conversation. 


e Handling exception situations. 


Processing stops when: 
e An exception occurs while the conversation is being allocated. 


e An exception occurs during the decoding of the DMU, or during the 
accessing of the server object or scheduling of further processing. 


e An exception occurs during the accessing of the queues. 


e An exception occurs on the conversation. 


For exceptions detected by DS_Receive, FSM_RECEIVE_MGR signals a machine 
to handle the building and sending of the REMU to DS_Send. For exceptions 
detected by DS_Send, and reported to DS_Receive on the conversation, 
FSM_RECEIVE_MGR signals a machine to handle the decoding of the SEMU that 
contains exception information from DS_Send. For all exceptions, 
FSM_RECEIVE_MGR issues the correct form of the Deallocate verb to terminate 
the conversation, and signals FSM_OPERATIONS_ MGR to log the exception and 
to notify the operator. 


FSM_RECEIVE_MGR has 3 key states that determine DS actions in exception 
situations. In what follows, “local conversation partner” refers to the DSU 
receiving the DMU on the conversation, and “remote conversation partner” 
refers to the DSU sending the DMU on the conversation. 


FSM_RECEIVE_ MGR—DEC_PEND State: In this state, the receive manager 
waits for other machines to report on whether all the DMUs were received or 
whether an exception occurred while a DMU was being received. The signals 
in this state have the following meanings: 


e SEND_SIDE_EXCEPT—LU 6.2 returned a PROG_ERROR_TRUNC or 
PROG_ERROR_NO_TRUNC On a verb issued by the local conversation partner, 
indicating that the remote conversation partner has detected an exception. 
FSM_RECEIVE MGR signals another machine, FSM_SEMU_DECODE, to 
handle the exception protocol, including receiving the SEMU from DS_Send. 


e RCV_SIDE_EXCEPT—Another machine in the hierarchy detected an excep- 
tion while parsing the DMU, storing the server object or enqueuing the dis- 
tribution. This is not an exception on the conversation, but rather an 
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exception detected at the local DSU. FSM_RECEIVE_ MGR signals another 
machine, FSM_REMU_ ENCODE, to handle the exception protocol, which 
includes sending a REMU to the remote conversation partner over the con- 
versation. 


¢ PROTOCOL_ERROR—If detected before the DMU is received completely, 
then LU 6.2 PS returned either what_received(SEND) or 
what_received(CONFIRM) to a Receive_And_Wait verb. If detected after the 
DMU has been received completely, then LU 6.2 PS returned either 
what_received(SEND) or what_received(DATA) to a Receive_And_Wait verb. 
The local conversation partner must assume that reliable communication 
cannot continue with the remote conversation partner. FSM RECEIVE MGR 
issues a Deallocate type(ABEND_PROG) to LU 6.2 PS to terminate the conver- 
sation abnormally. 


e CONVERSATION _FAILURE—LU 6.2 PS returns one of the following return 
codes on a verb that DS has issued: 


— ALLOCATION_ERROR—A conversation could not be allocated, no data has 
been able to flow. 


— DEALLOCATE_NORMAL—Although this is an improper DS usage of LU 6.2, 
the conversation is no longer available, and the condition is signalled 
as a CONVERSATION FAILURE. It is logged at the local DSU as an 
improper DS usage of LU 6.2, however. 


— Deallocate ABEND _PROG—The remote conversation partner has detected 
an exception that prevents further communication and has issued a 
Deallocate type(ABEND_PROG), or the remote LU has signalled a remote 
program abend condition. 


— RESOURCE_FAILURE—The session carrying the conversation has been lost. 


In each of these cases, the conversation is no longer active, and DS issues 
a Deallocate type(LOCAL) to terminate the local side of the conversation. 


FSM_RECEIVE_MGR—SND_EXPT State: In this state, the receive manager 
waits for a report on the progress of the exception protocol following the 
detection of an exception by the remote conversation partner. The signals in 
this state have the following meanings: 


e RCV_SIDE_EXCEPT— FSM_SEMU_DECODE detected an exception while 
parsing the SEMU. This is not an exception on the conversation, but rather 
an exception detected at the local DSU. FSM_SEMU_DECODE does not 
return this signal until a Deallocate NORMAL is returned by LU 6.2 PS toa 
Receive_And_ Wait verb. FSM_RECEIVE_ MGR completes the protocol by 
issuing a Deallocate type(LOCAL) verb. 


« PROTOCOL ERROR—If detected before the SEMU is received completely, 
then LU 6.2 PS returned either what_received(SEND) or 
what_received(CONFIRM) to a Receive _And_ Wait verb. If detected after the 
SEMU has been received completely, then LU 6.2 PS returned 
what_received(SEND), what_received(CONFIRM), or what_received(DATA) to a 
Receive _And_Wait verb. This exception can also occur if LU 6.2 PS returns 
a PROG_ERROR_PURGING, PROG_ERROR_TRUNC, OF PROG_ERROR_NO_TRUNC to a 
Receive_And_Wait verb. The local conversation partner must assume that 
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reliable communication cannot continue with the remote conversation 
partner. FSM RECEIVE MGR issues a Deallocate fype(ABEND_PROG) to ter- 
minate the conversation abnormally. 


¢ CONVERSATION FAILURE—LU 6.2 PS returns one of the following return 
codes on a verb that DS has issued: 


— Deallocate NORMAL—{(if received before the SEMU is received com- 
pletely). Although this is an improper DS usage of LU 6.2, the conversa- 
tion is no longer available, and the condition is signalled as a 
CONVERSATION FAILURE. It is logged at the local DSU as an improper 
DS usage of LU 6.2, however. 


— Deallocate ABEND _PROG—The remote conversation partner has detected 
an exception that prevents further communication and has issued a 
Deallocate type(ABEND PROG), or the remote LU has signalled a remote 
program abend condition. 


— RESOURCE_FAILURE—The session carrying the conversation has been lost. 


in each of these cases, the conversation is no longer active, and DS issues 
a Deallocate type(LOCAL) to terminate the local side of the conversation. 


e ERP_COMPLETE—A SEMU has been received successfully, and the remote 
conversation partner has terminated the conversation, which is indicated by 
a Deallocate NORMAL being returned by LU 6.2 PS to a Receive _And_Wait 
verb. FSM_RECEIVE_MGR terminates the local side of the conversation 
with Deallocate type(LOCAL) and logs the exception information sent by the 
remote conversation partner. 


FSM_RECEIVE_MGR—RCV_EXPT State: In this state, the receive manager 
waits for a report on the progress of the exception protocol following the 
detection of an exception by the local conversation partner. The signals in this 
state have the following meanings: 


e RCV_SIDE_EXCEPT— FSM_REMU_ ENCODE detected an exception in 
building the REMU. This is not an exception on the conversation, but rather 
an exception detected at the local DSU. The exception protocol cannot con- 
tinue and FSM_RECEIVE_MGR issues a Deallocate type(ABEND_PROG) to 
signal this to the remote conversation partner. 


e PROTOCOL_ERROR—This exception occurs if LU 6.2 PS returns a 
PROG_ERROR_PURGING to a Send_Data verb used by FSM_REMU_ENCODE. 
The local conversation partner must assume that reliable communication 
cannot continue with the remote conversation partner. FSM RECEIVE MGR 
issues a Deallocate type(ABEND_PROG) to terminate the conversation abnor- 
mally. 


¢ CONVERSATION _FAILURE—LU 6.2 PS returns one of the following return 
codes on a verb that DS has issued: 


— Deallocate ABEND_PROG—The remote conversation partner has detected 
an exception that prevents further communication, and has issued a 
Deallocate type(ABEND_PROG), or the remote LU has signalled a remote 
program abend condition. 


— RESOURCE_FAILURE—The session carrying the conversation has been lost. 
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— Deallocate NORMAL—This return code is returned as a conversation 
exception in the following circumstances: 


The local and remote conversation partners have both issued 
Send_Error verbs, but the exception indication is not received by the 
remote conversation partner until it (the remote conversation partner) 
issues a Deallocate type(FLUSH). In this case, the conversation is gone, 
but no improper DS usage of LU 6.2 has occurred. The local conversa- 
tion partner cannot send the REMU, and must simply log the exception 
locally. 


In each of the CONVERSATION FAILURE cases, the conversation is no 
longer active, and DS issues a Deallocate type(LOCAL) to terminate the local 
side of the exception. 


e ERP_COMPLETE—A REMU has been sent successfully to the remote con- 
versation partner. DS issues a Deallocate type(FLUSH) to terminate the con- 
versation and signal the remote conversation partner that the exception 
protocol is complete. 
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Function: This finite-state machine describes the functional processing for the receive manager of 
DS_Receive transaction program. For a further description, see “FSM_RECEIVE_MGR” on 
page 313. 


This FSM gets control from one of the following: 
¢ Signals from finite-state machines providing common services: 


— START_TRANSACTION from FSM_SCHED_MGR 
— OPERATIONS COMPLETE from FSM_OPERATIONS_MGR 


e Signals from LU 6.2 presentation services: 


— ATTACH from LU 6.2 when DS_Send issues Allocate 

— OK from Allocate, Deallocate FLUSH, Deallocate LocAL, Deallocate AREND 
— ALLOC_PARAM_ERROR from Allocate 

— ALLOCATION_ERROR from Allocate 


¢ Signals from lower-level DS_Receive finite-state machines: 


~ END_DMUS from FSM_DIST_DECODE_CONTROL 
— SEND_SIDE_EXCEPT from FSM_DIST_DECODE_CONTROL 
— RCV_SIDE_EXCEPT 
— from FSM_DIST_DECODE_CONTROL 
— from FSM_REMU_ENCODE 
— from FSM_SEMU_DECODE 
— PROTOCOL_ERROR 
— from FSM_DIST_DECODE_CONTROL 
— from FSM_REMU_ENCODE 
— from FSM_SEMU_DECODE 
— CONVERSATION_FAILURE 
— from FSM_DIST_DECODE_CONTROL 
— from FSM_REMU_ENCODE 
— from FSM_SEMU_DECODE 
— ERP_COMPLETE from FSM_SEMU_DECODE, FSM_REMU_ENCODE 
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Signal LU 6.2 presentation services with ALLOCATE to establish the conversation with DS_Send. 


Signal FSM_DIST_DECODE_CONTROL with DECODE to control the receiving and decoding of the 
DMU from DS_Send. 


Signal FSM_OPERATIONS_MGR with LOG_MESSAGE_EXCEPT for logging and operator messages. 


Signal LU 6.2 presentation services with DEALLOCATE_ LOCAL to deallocate the conversation 

locally. 

Signal FSM_SEMU_DECODE with DECODE_SEMU to control the protocols for an exception encount- 
ered by DS_Send. 


Signal FSM_REMU_ENCODE with ENCODE_REMU to control the building and sending of the REMU 
used to provide exception information from DS_Receive to DS_Send. 


Signal LU 6.2 presentation services with DEALLOCATE_ABEND to deallocate the conversation abnor- 
mally. 

Signal LU 6.2 presentation services with DEALLOCATE_FLUSH to signal the partner that no more 
DMUs should be sent. 


Signal LU 6.2 presentation services with GET_ATTRIBUTES. Signal FSM_DIST_DECODE_CONTROL 
with DECODE to control the receiving and decoding of the DMU from DS_Send. 
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FSM_DIST_DECODE_CONTROL 
This machine sequences the receiving of the DMU at a DSU and responds prop- 
erly to the Confirm request from the remote conversation partner. | 


This machine checks that the parts of the DMU are received and that they can 
be parsed without exceptions. Once the entire DMU has been received and 
parsed, the machine waits for a Confirm from the remote conversation partner 
(DS_Send) and causes the distribution to be put on the router-director queue. 
After these operations have been successfully completed, Confirmed is sig- 
nalled to the remote conversation partner. 


Exceptions in decoding result in a RCV_SIDE_EXCEPT signal to 
FSM_RECEIVE_MGR. Exceptions detected by DS_Send indicating that 
DS_Receive has violated the DS protocols regarding usage of LU 6.2 result in a 
PROTOCOL_ERROR signal to FSM_RECEIVE_MGR. Any other exceptions 
detected by DS_Send during transmission of the DMU result in a 
SEND_SIDE_EXCEPT signal to FSM_RECEIVE_MGR, and exceptions on the con- 
versation result in a CONVERSATION FAILURE signal to FSM_RECEIVE_MGR. 


Exceptions in receiving a DMU are reported by 
FSM_RCV_CONVERSATION_MGR. If the initial call to 
FSM_RCV_CONVERSATION_MGR does not return a signal of OK, this machine 
passes the available exception information to FSM_RECEIVE_MGR. If a subse- 
quent call to FSM_RCV_CONVERSATION_MGR results in an exception, this 
machine signals FSM_SRVR_OBJECT_WRITE with CLEANUP_OBJECT to delete 
any portion of the server object that may exist. 


When a DMU/Confirm/Confirmed sequence is complete, this machine enters a 
state to wait for the next DMU to flow on the LU 6.2 conversation. When the 
remote conversation partner deallocates the conversation normally, this 
machine signals FSM_RECEIVE_MGR with END_DMUS to indicate the conversa- 
tion should be terminated locally. 


If FSM_RCV_CONVERSATION_MGR returns a signal of DEALLOCATE_NORMAL 
before the DMU/Confirm/Confirmed sequence is complete, this machine signals 
FSM_RECEIVE_MGR with CONVERSATION FAILURE. 


The exceptions that can be signalled from this machine are 
SEND_SIDE_EXCEPT, RCV_SIDE_EXCEPT, CONVERSATION FAILURE, and 
PROTOCOL_ERROR. The handling of these exceptions is described in 
“FSM_RECEIVE_MGR—DEC_PEND State” on page 313. Although it is not 
shown in this machine, for an unsuccessful server function, 
FSM_OPERATIONS_ MGR should also be signalled with 
MESSAGE_TO_OPERATOR and passed the message that the DS lock count on 
the server object could not be successfully decremented. 
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Function: This finite-state machine describes the functional processing for controlling the receiving and 


parsing of the DMUs. For a further description, see “FSM_DIST_DECODE_CONTROL” on 
page 320. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_ Receive finite-state machines: 


— DECODE from FSM_RECEIVE_MGR 


Signals from lower-level DS_Receive finite-state machines: 


OBJECT_OK from FSM_SRVR_OBJECT_WRITE 

OBJECT _NOT_OK from FSM_SRVR_OBJECT_WRITE 

OK from FSM_RCV_CONVERSATION_ MGR 

SEND_SIDE_EXCEPT from FSM_RCV_CONVERSATION MGR 
CONVERSATION FAILURE from FSM_RCV_CONVERSATION._ MGR 


PROTOCOL_ERROR from FSM_RCV_CONVERSATION_MGR 
END _DMUS from FSM_RCV_CONVERSATION_MGR 

ENQ SCHED OK from FSM_RCV_ENQ_ SCHED 

ENQ_ SCHED NOT_OK from FSM_RCV_ENQ SCHED 


Signals from finite-state machines providing common services: 


— OBJECT_OK from SERVER_MGR 
— OBJECT _NOT_OK from SERVER_MGR 


Signals from “PARSER” on page 359 


PARSE_OK 
PARSE_OK_OBJECT 
PARSE_COMPLETE 
PARSE_NOT_OK 
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Output 

Code 

Signal FSM_RCV_CONVERSATION_MGR with RECEIVE_BUFFER to receive information from LU 6.2 
PS. 


Signal PARSER with PARSE to parse information received. 


Signal FSM_SRVR_OBJECT_WRITE with WRITE_OBJECT to write the information and initialize for 


writing if not yet initialized. 


Signal FSM_SRVR_OBJECT_WRITE with END_DMU to terminate writing. 


Signal FSM_RCV_CONVERSATION_MGR with WAIT_CONFIRM to indicate that a DMU has been com- 
pletely received and that the CONFIRM indicator should be the next indicator from DS Send. 


Signal FSM_RCV_ENQ_ SCHED with ENQ_SCHED to place the distribution on the router-director 
queue and schedule DS_Router_Director. 


Signal FSM_RCV_CONVERSATION_MGR with CONFIRMED to indicate that DS_Receive has accepted 
responsibility for the DMU and that Confirmed should be sent to DS_Send. 


Signal FSM_RECEIVE_MGR with SEND_SIDE_EXCEPT to indicate that an exception has occurred in 
DS_Send and that the sender exception protocols should be followed. 


Signal FSM_RECEIVE_MGR with CONVERSATION FAILURE to indicate that an exception has 
occurred in the conversation between DS_Send and DS_Receive. 


Signal FSM_RECEIVE_MGR with PROTOCOL_ERROR to indicate that a protocol exception has 
occurred in the conversation between DS_Send and DS_Receive. 


Signal FSM_RECEIVE_MGR with END_DMUS to indicate that the Deallocate NORMAL return code has 
been received from DS_Send indicating that DS_Send will send no more DMUs. 


Signal FSM_SRVR_OBJECT_WRITE with CLEANUP_OBJECT to delete any portion of the object that 
may exist. This is for exception cleanup and consists of a Terminate_Write, if necessary, followed by 
decrementing the DS lock count. 


Signal FSM_RECEIVE_MGR with RCV_SIDE_EXCEPT to indicate that an exception has occurred in 
parsing or in scheduling further processing, and that the receiver exception protocols should be fol- 
lowed. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to indicate that the DS lock count should be dec- 


remented and the object deleted if the lock count reaches 0. If no server object exists, 
SERVER_MGR returns OBJECT_OK. 
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FSM_RCV_ENQ_SCHED 
This machine controls the placing of the distribution on the router-director 
queue and the scheduling of DS_Router_Director. The request for this function 
is from FSM_DIST_DECODE_CONTROL. 


The sequence of functions performed is as follows: 


e Issue WRITEQ to put the distribution on the router-director queue. 

e Issue the request to start the DS_Router_Director transaction program. 

e Issue RELEASEQ to remove the in-use mark from the entry on the router- 
director queue so that it is available for processing. 


Exceptions can occur in enqueuing or scheduling. For enqueuing or scheduling 
exceptions, this machine signals to SERVER_MGR to decrement the server 
object DS lock count, and delete the server object if both the DS and agent lock 
counts are 0. For scheduling exceptions, the queue entry is dequeued. 


For any exception, this machine signals ENQ SCHED _NOT_OK to 
FSM_DIST_DECODE_CONTROL. Although it is not shown in this machine, for 
an unsuccessful server, queue, or scheduling function, 
FSM_OPERATIONS_MGR should also be signalled with 
MESSAGE_TO_OPERATOR and passed the message that the function could not 
be completed, and that, while FSM_RCV_ENQ SCHED was handling the excep- 
tion, another exception occurred. 
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This finite-state machine describes the functional processing in DS_Receive to place the distrib- 
ution on the router-director queue and schedule DS_Router_Director. For a further description, 
see “FSM RCV_ENQ SCHED” on page 324. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines: 
— ENQ_SCHED from FSM_DIST_DECODE_CONTROL 


Signals from finite-state machines providing common services: 


OBJECT_OK from SERVER_MGR 

OBJECT_NOT_OK from SERVER_MGR 

QUEUE_OK from QUEUE_MGR 

QUEUE_NOT_OK from QUEUE_MGR 
SCHED_FUNCTION_OK from FSM_SCHED_MGR 
SCHED FUNCTION NOT_OK from FSM SCHED MGR 
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Signal QUEVE_MGR with WRITEQ to place the distribution on the router-director queue. 
Signal FSM_SCHED_MGR with START_REQUEST to schedule DS_Router_Director. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to indicate that the DS lock count should be dec- 
remented and the object deleted if both the DS and agent lock counts reach 0. If no server object 
exists, SERVER_MGR returns OBJECT_OK. 


Signal FSM_DIST_DECODE_CONTROL with ENQ_ SCHED_OK to indicate that the distribution was suc- 
cessfully placed on the router-director queue and that DS_Router_Director was scheduled. 


Signal QUEVE_MGR with DEQ to remove the distribution from the router-director queue. 


Signal FSM_DIST_DECODE_CONTROL with ENQ_SCHED_NOT_OK to indicate that an exception 
occurred in placing the distribution on the router-director queue, or in scheduling 
DS_Router_Director. Cleanup of the queues and the object has taken place. 


Signal QUEVE_MGR with RELEASEQ to remove the in-use mark from the entry on the router-director 
queue. The entry is then available for processing by DS_Router_Director. 
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FSM_SRVR_OBJECT_WRITE 


This machine controls the writing of the server object. The request for this 
function is from FSM_DIST_DECODE_CONTROL. 


For an input signal of WRITE_OBJECT, this machine signals WRITE to the server 
manager. For an input signal of END_DMU, this machine signals 
TERMINATE_WRITE to the server manager. For an input signal of 
CLEANUP_OBJECT, prior to a successful Initiate_Write operation, this machine 
signals OBJECT_OK. For any subsequent signal of CLEANUP_OBJECT, this 
machine signals CLEANUP_OBJECT to SERVER_MGR to perform a 
Terminate_Write operation and decrement the DS server object lock. 


The general server is used to write the server object. If direct store is to be 

performed, the receive-time processing required for direct store is perforrned 
prior to writing the server object. Based on the receive-time processing, the 
specific server can be used to store the server object rather than the general 
server. For a description of direct store, see Chapter 1. The server name is 
passed to SERVER_MGR. 


Exceptions can occur in writing the server object. For any exception occurring 
after the initial WRITE, a Terminate_Write is issued and the DS lock count dec- 
remented. In case of a failure from the server, FSM_OPERATIONS_MGR is sig- 
nalled with MESSAGE_TO_OPERATOR to notify the operator that a server object 
cannot be accessed as requested. This function is not shown in this machine. 


Exceptions in writing result in an OBJECT_NOT_OK signal to 
FSM_DIST_DECODE_CONTROL and RCV_SIDE_EXCEPT signal to 
FSM_RECEIVE_ MGR. For a further description of these exceptions and the 
processing that results, see “FSM_RECEIVE_MGR—DEC_PEND State” on 
page 313. 
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This finite-state machine describes the functional processing for writing the object. For a 
further description, see “FSM _SRVR_OBJECT_WRITE” on page 328. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines: 
— WRITE_OBJECT from FSM_DIST_DECODE_CONTROL 


— END _DMU from FSM_DIST_DECODE_CONTROL 
— CLEANUP OBJECT from FSM_DIST_DECODE_CONTROL 


¢ Signals from machines providing common services: 
— OBJECT_OK from SERVER_MGR 


= <a <a “a 


— OBJECT_NOT_OK from SERVER_MGR 
WRITE OBJECT 
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Signal SERVER_MGR with WRITE to write a portion of the object. 


Signal FSM_DIST_DECODE_CONTROL with OBJECT_OK to indicate that the portion of the object has 
been written, and the access terminated if the end of the DMU has been reached. If no object exists, 
OK is also signalled. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count. 


Signal FSM_DIST_DECODE_CONTROL with OBJECT_NOT_OK to indicate that an exception has 
occurred during the writing of the object. 


Signal SERVER_MGR with CLEANUP_OBJECT to delete any portion of the object that may exist. This 
is for exception cleanup and consists of a Terminate_Write, if necessary, followed by decrementing 
the DS lock count. 


Signal SERVER_MGR with TERMINATE _WRITE to terminate the access to the object. 
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FSM_RCV_CONVERSATION_MGR 
FSM_RCV_CONVERSATION_MGR issues Receive_And_Wait for receiving the 
DMU and the confirm indicator, and issues Confirmed to indicate that 
DS_ Receive accepts responsibility for the DMU. This machine receives input 
signals from FSM_DIST_DECODE_CONTROL. 


Figure 50 classifies the possible exceptions. 


Return Code Reported As Explanation | 


ALLOCATION ERROR CONVERSATION _FAILURE| Conversation was never allocated. 
DEALLOCATE NORMAL CONVERSATION FAILURE} In some cases, a protocol! error was detected; 
conversation terminated. 


DEALLOCATE ABEND PROG] CONVERSATION FAILURE) Abend condition or protocol error was detected by 
partner TP. — 

PROG ERROR TRUNC | SEND _SIDE_ERROR DS_Send issued a Send_Error indicating an error. 

PROG ERROR NO TRUNC | SEND SIDE_ERROR DS_Send issued a Send_Error indicating an error. 

RESOURCE FAILURE CONVERSATION FAILURE] Conversation was lost because the session was lost. 


Figure 50. Classification of NOT-OK Return Codes by FSM_RCV_CONVERSATION_ MGR 
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This finite-state machine describes the functional processing to control receiving the data from | 
an adjacent DSU. For a further description, see “FSM _RCV_CONVERSATION_ MGR” on 
page 330. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines: 


— RECEIVE_BUFFER from FSM_DIST_DECODE_CONTROL 
— WAIT_CONFIRM from FSM_DIST_DECODE_CONTROL 
— CONFIRMED from FSM_DIST_DECODE_CONTROL 


Signals from LU 6.2 presentation services: 


ALLOCATION_ERROR from Receive_And_Wait 
RESOURCE_FAILURE from Receive_And_Wait 

PROG_ERROR from Receive_And_Wait 

DEALLOCATE_ABEND from Receive_And_Wait 
DEALLOCATE_NORMAL from Receive_And_Wait 
RECEIVE_AND_WAIT_DATA_COMPLETE from Receive_And_Wait 
RECEIVE_AND_WAIT_DATA_INCOMPLETE from Receive_And_Wait 
RECEIVE_AND_WAIT_LL_TRUNCATED from Receive_And_Wait 
RECEIVE_AND_WAIT_SEND from Receive_And_Wait 
RECEIVE_AND_WAIT_CONFIRM from Receive_And_Wait 
RECEIVE_AND_WAIT_CONFIRM_DEALLOCATE from Receive_And_Wait 
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Output 
Code 
Signal LU 6.2 presentation services with RECEIVE_AND_WAIT to indicate that data can be accepted. 


Signal LU 6.2 presentation services with CONFIRMED to indicate that responsibility for the DMU has 
been accepted by DS_Receive. 

Signal FSM_DIST_DECODE_CONTROL with OK to indicate that the LU 6.2 request completed suc- 
cessfully. 


Signal FSM_DIST_DECODE_CONTROL with OK to indicate that the LU 6.2 request completed suc- 
cessfully. 


Signal FSM_DIST_DECODE_CONTROL with CONVERSATION_FAILURE to indicate that an exception 
occurred on the conversation between DS_ Send and DS_eceive. 


Signal FSM_DIST_DECODE_CONTROL with PROTOCOL_ERROR to indicate that an error in the proto- 
cols has occurred between DS_Send and DS_Receive. 


Signal FSM_DIST_DECODE_CONTROL with END_DMUS. This indicates that either a Deallocate 
NORMAL has been received from DS_Send, or the conversation is already deallocated; i.e., DS Send 
issued Deallocate TYPE(SYNC_LEVEL) on the previous DMU. Receiving a Deallocate NORMAL after the 
prefix is a protocol error, but is treated as a conversation failure because the conversation resource 
is no longer available. 


Signal FSM_DIST_DECODE_CONTROL with SEND_SIDE_EXCEPT to indicate that DS_Send has 
encountered an exception. 
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FSM_SEMU_DECODE | 
This machine receives exception information from DS_Send after DS Send has 
encountered an exception in building or sending a DMU. This function is 
requested from FSM_RECEIVE_MGR signalling DECODE_SEMU. 


The DS protocol for this exception is: 


e Issue Receive_And_Wait for the SEMU forward abort indicator. 
¢ Parse the SEMU containing the exception information. 
e Issue Receive_And_ Wait for the Deallocate NORMAL. 


Once FSM_SEMU_DECODE receives and parses the SEMU, it passes the excep- 
tion fields to FSM_RECEIVE_MGR with the signal ERP_COMPLETE. Exceptions 
can occur in receiving the SEMU on the LU 6.2 conversation or in parsing the 
exception information. For a further description of these exceptions and the 
processing that results, see “FSM_RECEIVE_MGR—SND_EXPT State” on 

page 314. . 
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This finite-state machine describes the functional processing for exception processing in 
DS_ Receive when the exception occurred on the sending side. For a further description, see 
“FSM_SEMU_DECODE” on page 334. 


This FSM gets control from one of the following: 


¢ Signals from higher-level DS_Receive finite-state machines: 
— DECODE_SEMU from FSM_RECEIVE_MGR 
Signals from PARSER: 


— PARSE_NOT_OK 
— PARSE _COMPLETE 


Signals from LU 6.2 presentation services: 


RCV_AND_WAIT_SEND 
RCV_AND_WAIT_CONFIRM 
RCV_AND_WAIT_CONFIRM_DEALLOCATE 
RCV_AND_WAIT_DATA_COMPLETE 
RCV_AND_WAIT_DATA_INCOMPLETE 
RCV_AND_WAIT_LL_ TRUNCATED 
RESOURCE_FAILURE 

PROG_ERROR 

DEALLOCATE_ABEND 
DEALLOCATE_NORMAL 
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Signal LU 6.2 presentation services with RECEIVE_AND_WAIT to receive exception information from 
DS_Send. 


Signal PARSER with PARSE_SEMU to parse the SEMU. 

Signal FSM_RECEIVE_MGR with PROTOCOL_ERROR to indicate that the proper protocols were not 
followed for exception processing. 

Signal FSM_RECEIVE_MGR with ERP_COMPLETE to indicate that exception processing completed 
and that appropriate deallocation should take place. 

Signal FSM_RECEIVE_MGR with CONVERSATION _ FAILURE to indicate that exception processing did 
not successfully complete. 

Signal FSM_RECEIVE_MGR with RCV_SIDE_EXCEPT to indicate that an exception occurred in parsing 
the SEMU. 
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FSM_REMU_ENCODE 
This machine indicates to DS_Send that an exception has occurred during the 
receiving or parsing of the DMU and passes to DS_Send the exception informa-_ 
tion in the REMU. The function is requested by FSM_RECEIVE_MGR signalling 
ENCODE_REMU. The exception information required for building the REMU is 
passed to FSM_REMU_ENCODE. 


The DS protocol for this processing is: 


e Issue a Send_Error to LU 6.2 presentation services. 

e Build an REMU containing the exception information and the name of the 
DSU detecting the exception. 

e Issue Send_Data(s) to LU 6.2 presentation services for the REMU. 


Exceptions can occur in the encoding process, and in sending the REMU on the 
LU 6.2 conversation. For a further description of these exceptions and the proc- 
essing that results, refer to “FSM_RECEIVE_.MGR—RCV_EXPT State” on 

page 315. 
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This finite-state machine describes the functional processing for exception processing in 
DS_Receive when the exception occurred on the receiving side. For a further description, see 
“FSM_REMU_ENCODE” on page 338. 


This FSM gets control from one of the following: 
¢ Signals from higher-level DS_Receive finite-state machines: 
— ENCODE_REMU from FSM_RECEIVE_MGR 
Signals from LU 6.2 presentation services: 


OK from Send_Error, Send_Data 
RESOURCE_FAILURE from Send_Error, Send_Data 
PROG_ERROR from Send_Data 
DEALLOCATE_ABEND from Send_Error, Send_ Data 
DEALLOCATE_ NORMAL from Send_Error. 


SEND_ERR 
RESET | PEND 


ENCODE REMU— 


PROG ERROR 
RESOURCE FAILURE 
DEALLOCATE NORMAL 


Signal LU 6.2 presentation services with SEND_ERROR to indicate to the partner that an exception 
was encountered on the receiving side. 


Build a REMU with the appropriate exception code (using a prefix correlation if one existed in the 
DMU prefix), and signal LU 6.2 presentation services with SEND_DATA to send the encoded informa- 


tion to the partner DSU. 


Signal FSM_RECEIVE_MGR with ERP_COMPLETE to indicate that exception processing has been 
completed and that appropriate deallocation should take place. 


Signal FSM_RECEIVE_MGR with CONVERSATION_FAILURE to indicate that an exception has 
occurred in ‘the conversation between DS_Send and DS __ Receive. 


| Signal FSM_RECEIVE_MGR with PROTOCOL_ERROR to indicate that the proper exception protocols 
were not followed for exception processing. 
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Common Services 


These machines provide functions to all the other machines in the formal 
model. Some implementations will provide some of these functions as part of 
their runtime environment; others will package them differently. Some of these 
functions are provided by all DS implementations: 


¢ FSM_OPERATIONS MGR 


— All DS implementations support some form of the release and hold func- 
tions for the queues, if queues are supported at the DS level of imple- 
mentation. 


— All DS implementations provide some logging when exceptions are 
detected. See Appendix C and Appendix E for rules for logging, and 
when logging takes place. 


¢ FSM_SCHED MGR 


The formal model presents two scheduling triggering mechanisms: Sched- 
uling based on the time of day, and scheduling based on the number of 
next-DSU queue entries. These scheduling mechanisms are electives. See 
Appendix C for electives. 7 
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Operations 


FSM_OPERATIONS MGR 


FSM_ FSM_ 


QUEUE_ 
CONTROL*|} [MGR 


SCHED_ MGR 


SERVER_ | {FSM FSM 


MESSAGE FSM_LOG 


* * * x 


FSM_ FSM_ FSM_ 
SCHED_| |LOG MESSAGE 
MGR * * 


* indicates those finite-state machines not formally specfied. 


For more details regarding the finite-state machines see: 


"FSM_OPERATIONS MGR" on page 342 
"FSM_SCHED_ MGR" on page 351 
"FSM_EXCEPT_TYPE" on page 348 
"QUEUE_MGR" on page 357 
"FSM_QUEUE_CONTROL" on page 348 


Figure 51. Operations FSM Hierarchy 


e @ © @ 


"SERVER_MGR" on page 354 

"FSM MESSAGE" on page 348 
"FSM_REPORT" on page 349 

"FSM_LOG" on page 349 
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FSM_OPERATIONS_ MGR | 
This machine controls the logging of exceptions, messages to the operator, 
queue control, and generation of reports. FSM_OPERATIONS MGR signals 
other FSMs to perform each of the functions. The requests for these functions 
are as follows: 


1. Exceptions in DS_Receive 


FSM_RECEIVE_MGR signals FSM_OPERATIONS MGR with 
LOG_MESSAGE_EXCEPT to perform the following: 


e Logging of an exception encountered in DS_Receive or indicated to 
DS_Receive by DS_ Send. 
e Sending a message to the operator. 


2. Exceptions in DS_Send | 
FSM_SEND_MGR signals FSM_OPERATIONS_MGR with: 


a. SEND_MU_EXCEPT to perform the following: 
¢ Logging of an exception encountered in DS_Send or indicated to 
DS_Send by DS Receive. 
e Sending a message to the operator. 
Queue control. _ 
Determination of retriable and nonretriable exceptions. 
Releasing of the queue entry if retriable. 
Removing of the queue entry, decrementing the server object DS 
lock count, and generating a report if nonretriable. 
b. LOG_MESSAGE_EXCEPT, to perform the following, if the exception is 
not on a particular MU: 
¢ Logging of the exception condition. 
e Sending a message to the operator. 


3. Exceptions in DS_Router_Director 


FSM_ROUTING DIRECTING MGR signals this machine with 
LOG MESSAGE EXCEPT, to perform the following, if the exception is not on 
a particular MU: ! 


e Logging of the exception condition. 
e Sending a message to the operator. 


FSM_DIRECTING_MGR and FSM_ROUTING MGR signal 
FSM_OPERATIONS MGR with ROUTING DIRECTING EXCEPT to perform the 
following: 


e Logging of the exception condition. 
e Sending a message to the operator. 
¢ Generation of a report. 


4. Exceptions during exception processing 


Any machine signals FSM_OPERATIONS_MGR with 
MESSAGE_TO_OPERATOR when exception processing is being performed, 
and an exception occurs during this processing. FSM_OPERATIONS_MGR 
signals FSM_MESSAGE to send a message to the operator. This generally 
signals conditions that the DSU cannot recover and that require assistance 
from the operator to clear up. 
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5. Other applications 


An operator signals FSM OPERATIONS MGR with SEND RELEASE HOLD, 
or RCV_RELEASE_HOLD to start DS_Send or DS_Receive transaction pro- 
grams. 
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Function: 


This finite-state machine describes the functional processing in operations for generating 
reports, logging, sending operator messages, and handling queue control. For a further 
description, see “FSM OPERATIONS MGR” on page 342. 


This FSM gets control from one of the following: 


Signals from routing and directing finite-state machines: 


— ROUTING_DIRECTING_EXCEPT from FSM_ROUTING MGR, FSM_DIRECTING MGR 

— LOG_MESSAGE_EXCEPT from FSM_ROUTING_DIRECTING_MGR 

— MESSAGE_TO_OPERATOR from any routing and directing finite-state machines needing 
to report an exception on an exception 


Signals from distribution transport finite-state machines: 


— SEND _MU_EXCEPT from FSM_SEND_MGR 

— LOG_MESSAGE_EXCEPT from FSM_RECEIVE_MGR, FSM_SEND_MGR 

— MESSAGE_TO_OPERATOR from any distribution transport finite-state machines needing 
to report an exception on an exception 


Signals from other applications (UPM): 


— SEND RELEASE HOLD from UPM_MSG FROM_ OPERATOR 
— RCV_RELEASE_HOLD from UPM_MSG_FROM_OPERATOR 


Signals from lower-level operations finite-state machines: 


— RETRIABLE_EXCEPT from FSM_EXCEPT_TYPE 

— NONRETRIABLE_EXCEPT from FSM_EXCEPT_TYPE 

— QUEUE_CONTROL_COMPLETE from FSM_QUEUE_CONTROL 
— LOGGING_OK from FSM_LOG 

— MESSAGE_OK from FSM_MESSAGE 

— REPORT_COMPLETE from FSM_REPORT 


Signals from finite-state machines providing common services: 


— QUEUE_OK from QUEUE_MGR 

— QUEUE NOT_OK from QUEUE_MGR 

— SCHED FUNCTION OK from FSM SCHED MGR 

— SCHED FUNCTION NOT_OK from FSM_SCHED_MGR 
— OBJECT_OK from SERVER_MGR 

— OBJECT NOT OK from SERVER_MGR 
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Output 

Code 

Signal FSM_EXCEPT_TYPE with EXCEPTION_CODE to determine if the exception is retriable or 
nonretriable. 


Signal FSM_QUEUE_CONTROL with SET_QUEUVE_ CONTROL to determine if the queues for the con- 
nection should be held, and, if so, then setting the hold. 


Signal FSM_LOG with LOG_EXCEPT to log the appropriate operands for the exception. 
Signal FSM_MESSAGE with DISPLAY_MESSAGE to display an exception message to the operator. 
Signal FSM_REPORT with GENERATE_REPORT to generate any requested asynchronous reports. 


Signal QUEVE_MGR with DEQ to remove the distribution from the next-DSU queue. The exception 
was determined to be nonretriable. 


Signal calling machine with OPERATIONS COMPLETE to indicate that the appropriate operations 
functions have been completed. These may not have been completed successfully. 


h Signal FSM_SCHED_MGR with OPR_START_SEND to indicate that an operator has requested that 
the send side be released and a DS_Send transaction program be scheduled. 


Signal FSM_SCHED_MGR with OPR_START_RECEIVE to indicate that an operator has requested that 
DS_Receive be scheduled so that the flow of DMUs can be resumed from DS_Send. 


Signal calling machine with OPERATIONS_NOT_OK to indicate that the appropriate operations func- 
tions have not been completed successfully. 


Signal QUEVE_MGR with RELEASEQ to remove the in-use mark from the entry on the next-DSU 
queue. The exception was determined to be retriable and, following the RELEASEQ, the entry will be 
available to DS_Send for processing. 


Signal SERVER_MGR with DECREMENT_OBJ_LOCK to decrement the DS lock count on the server 
object. If no server object exists, SERVER_MGR returns OBJECT_OK. 
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FSM_EXCEPT_TYPE 


Determines if an exception is retriable or nonretriable. The request for this 
function is from FSM OPERATIONS MGR, and the exception information is 
passed for analysis. 


FSM_EXCEPT_TYPE determines from the exception information if the DMU can 
possibly be transmitted at a later time, and, if so, signals 
FSM_OPERATIONS MGR with RETRIABLE_ EXCEPT. If the exception is such 
that something in the DMU is incorrect, and will never successfully be sent until 
the DMU changes (for example, the server name), FSM _EXCEPT_TYPE signals 
FSM_OPERATIONS_MGR with NONRETRIABLE_ EXCEPT. 


For retriable exceptions, FSM EXCEPT TYPE logs the DMU unique identifier in 
a retry log. On subsequent exceptions, FSM _EXCEPT_TYPE searches the retry 
log, and if the exception is tried and fails some specified number of times, 
FSM_EXCEPT_TYPE signals FSM_OPERATIONS_ MGR with 
NONRETRIABLE_EXCEPT. 


FSM_QUEUE_CONTROL 


FSM_MESSAGE 


This machine determines if the next-DSU queues for the connection should be 
held based on the exception encountered, and, if so, sets the exception-hold 
indicator. The request for this function is from FSM_OPERATIONS_MGR and 
the exception information is passed. 


FSM QUEUE CONTROL examines the exception, and determines if it is reason- 
able that other DMUs can successfully be transmitted on the connection speci- 
fied. If so, the exception-hold is not set, and this machine signals 
FSM_OPERATIONS_MGR with QUEUE _CONTROL_COMPLETE. An example of 
this is an unknown server name that flows in the DMU. This exception does not 
necessarily affect the next DMU that may flow. 


If FSM QUEUE CONTROL examines the exception and determines that it is 
likely that more DMUs will fail, FSM_QUEUE CONTROL sets the exception-hold 
indicator on the queues for the specified connection in a table containing infor- 
mation about these queues. FSM_QUEUE CONTROL signals 
FSM_OPERATIONS_ MGR with QUEUE_CONTROL_COMPLETE. An example of 
an exception that implies that other DMUs will likely fail is an out-of-space con- 
dition on the receiver side. 


This machine sends a message to the operator concerning the current excep- 
tion condition. The request for this function is from FSM_OPERATIONS MGR or 
FSM_REPORT signalling DISPLAY_MESSAGE. The exception information 
needed to format the message is passed. 


FSM_MESSAGE formats the message, then sends the message by signalling 
UPM_MSG_TO_OPERATOR. FSM_MESSAGE signals the calling machine with 
MESSAGE_OK. 
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FSM_REPORT 
This machine generates a distribution report for exceptions encountered in 
DS Router_Director, or exceptions in DS_Send that are nonretriable. The 
request for this function is from FSM_OPERATIONS MGR signalling 
GENERATE REPORT. The exception information plus the distribution on which 
the exception occurred is passed. This includes the list of exception destina- 
tions. 


FSM REPORT manages the following: 


¢ Issuing WRITEQ to put the distribution on the router-director queue. 

e Issuing the request to schedule the transaction DS_Router_Director. 

e Issuing RELEASEQ to remove the in-use mark from the queue entry on the 
router-director queue to make it available for processing. 


If exceptions occur in the queue or scheduling function, FSM REPORT signals 
FSM_LOG to log the failure, and FSM_MESSAGE to notify the operator. In the 
case of a scheduling exception, FSM_REPORT also signals QUEUE MGR with 
DEQ to remove the entry from the router-director queue. 


In addition to the above, if FSM_OPERATIONS_MGR was signalled by 
FSM_DIRECTING MGR and if the distribution could not be enqueued for 
delivery to any of the local destinations, then SERVER_MGR is signalled with 
BACKOUT, and any returned server report is queued for the destination agent. 


FSM_REPORT signals FSM_OPERATIONS_MGR with REPORT_COMPLETE in 
any case. 


FSM_LOG 
This machine logs the exception in the DMU exception log. The request for this 
function is from FSM OPERATIONS MGR or from FSM_REPORT signalling 
LOG_EXCEPT. The exception information is passed. The information logged for 
a given condition is listed in Appendix E. 


FSM_LOG signals the calling machine with LOGGING OK. 
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Scheduler 


FSM_SCHED MGR 


FSM_CHECK_TP FSM_CHECK_TOD FSM_CHECK_ UPM_START_TP 


QUEVE_DEPTH 


* * * 


* indicates those finite-state machines not formally specified. 
For more details regarding the finite-state machines, see: 
© "FSM _SCHED_MGR" on page 351 


* "FSM CHECK TP" on page 354 
© "FSM_CHECK_TOD" on page 354 


© "FSM_CHECK_QUEUE_DEPTH" on page 354 
* "UPM_START_TP" on page 354 


Figure 52. Scheduler Manager FSM Hierarchy 


350 SNA/Distribution Services Reference 


FSM_ SCHED MGR 


The scheduler manager issues START_TRANSACTION to UPM_START_TP for 
any DS transaction program and for any destination agent program specified. 
The signalling machine passes the name of the transaction program to start 
and the queue identifier, if appropriate. 


FSM_SCHED_MGR processes the following signals: 


* OPR_START_RECEIVE to start DS_Receive. 
¢ OPR_START_SEND to start DS_Send. 
¢ START_REQUEST to start: 

— DS_Router_Director. 

— An agent. 

— DS_Send. 


For DS_Send, one or both of the following occur: 

— FSM SCHED _MGR signals FSM _CHECK_TOD to determine if there 
is any scheduling by time of day for the next-DSU queue. If there is, 
the time of day is specified on the START_TRANSACTION and the 
system resource manager starts the transaction program at the 
specified time. 

— If no time of day is specified, FSM SCHED MGR signals 
FSM_CHECK QUEUE DEPTH to determine if there is a queue depth 
trigger for starting DS_Send for the specified next-DSU queue. If the 
queue depth has been reached or no queue depth is set, 
FSM_SCHED_MGR issues START_TRANSACTION for DS_Send. If 
the queue depth has not been reached, this machine returns without 
issuing a START_TRANSACTION. | 


If START_TRANSACTION is not successful, FSM SCHED MGR signals the 


calling machine SCHED FUNCTION NOT_OK and passes the available excep- 
tion information. 
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This finite-state machine describes the functional processing for scheduling DS_Router_Director 
service transaction program, DS_Send service transaction program, DS_Receive service trans- 
action program, or the destination agent. For a further description, see “FSM _SCHED_MGR” 
on page 351. 


This FSM gets control from one of the following: 


¢ Signals from presentation services, DS_Router_Director, DS_Send, DS_Receive: 


— START_REQUEST from FSM_LOCAL_SCHED, FSM_REMOTE_SCHED, 
FSM_RCV_ENQ SCHED, DS_RCV_ENQ SCHED 


Signals from finite-state machines providing common services: 


— OPR_START_SEND from FSM_OPERATIONS_MGR 
— OPR_START_RECEIVE from FSM_OPERATIONS_MGR 


Signals from lower-level finite-state machines: 


DS_ROUTER_DIRECTOR from FSM_CHECK_TP 

DS_SEND from FSM_CHECK_TP 

AGENT from FSM_CHECK_TP 

TOD_SET from FSM_CHECK_TOD 

NO_TOD_SET from FSM_CHECK_TOD 

QUEUE_DEPTH_REACHED from FSM_CHECK_QUEUE_DEPTH 
NO_QUEUE_DEPTH_SET from FSM_CHECK_QUEUE_DEPTH 
QUEUE_DEPTH_NOT_REACHED from FSM_CHECK_QUEUE_DEPTH 
START_TRANSACTION_OK from UPM_START_TP 
START_TRANSACTION NOT_OK from UPM_START_TP 


| QUEUE 
RESET TP CHECK | TOD CHECK DEPTH START PEND 
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Output 
Code 
Signal FSM_CHECK_TP with CHECK_TP to determine what transaction program is being requested. 


Signal UPM_START_TP with START_TRANSACTION passing DS_SEND as the target_tpn and 
WHEN_SESSION_PREALLOCATED as the indicator of when the TP should be started. 


Signal UPM_START_TP with START_TRANSACTION passing DS_RECEIVE as the target_tpn and 
WHEN_SESSION_PREALLOCATED as the indicator of when the TP should be started. 


Signal UPM_START_TP with START_TRANSACTION passing DS_ROUTER_DIRECTOR as the target_tpn 
and NO_PREALLOCATION_ REQUIRED as the indicator of when the TP should be started. 


Signal FSM_CHECK_TOD with CHECK_TOD to determine if time of day scheduling has been defined 
for this next-DSU queue. 
—_ Signal UPM_START_TP with START_TRANSACTION passing the agent as the target_ton and 


NO_PREALLOCATION_REQUIRED as the indicator of when the TP should be started. 


Signal calling machine with SCHED _FUNCTION_OK to indicate that the scheduling request has been 
made if a transaction program is to be started, or that currently no TP is to be started. 


Signal UPM_START_TP with START_TRANSACTION passing DS_SEND as the target_tpn and 
WHEN_SESSION_PREALLOCATED and the time of day as indicators of when the TP should be started. 


Signal FSM_CHECK_QUEUE_DEPTH with CHECK_QUEUE_DEPTH to determine if the scheduled queue 
depth has been reached to indicate that DS_Send should be scheduled. 


Signal calling machine with SCHED_FUNCTION_NOT_OK to indicate that the scheduling request did 
not receive an OK return code. 
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FSM_CHECK_TP 


FSM_CHECK_TOD 


Determines the transaction program name to be started. The transaction 
program name passed to FSM_SCHED_MGR is passed to this machine with the _ 
signal CHECK_TP. | 


The output of this machine is one of the following signals to FSM _SCHED_MGR: 


¢ DS ROUTER DIRECTOR 
¢ DS SEND 
© AGENT 


For the signal AGENT, the transaction program name is passed. 


Determines if any time of day scheduling is defined for the specified LU name, 
and mode name, and, if so, passes the time of day to FSM_SCHED MGR. The 
request for this function is from FSM_SCHED_MGR. 


This machine examines a table that contains attributes for the LU name, mode 
name passed. If atime of day list is defined, the next time of day following the 
current time is chosen, FSM_CHECK_TOD signals FSM_SCHED_MGR with 
TOD_SET and passes the time of day. 


If no time of day is defined, FSM_CHECK_TOD signals FSM_SCHED_MGR with 
NO_TOD_SET. 


FSM_CHECK _-QUEUE_ DEPTH 


UPM_START_TP 


SERVER_MGR 


Determines if queue-depth scheduling is defined for the specified LU name, and 
mode name, and if so, checks whether the queue depth has been reached. The 
request for this function is from FSM_SCHED_MGR. 


This machine examines a table that contains attributes for the LU name, mode 
name passed to this machine. If a schedule queue depth is defined, it is com- 
pared to the current queue depth. If the current queue depth is equal to or 
greater than the schedule queue depth, FSM_CHECK_QUEUE DEPTH signals 
FSM SCHED _MGR with QUEUE_DEPTH_REACHED. If not, this machine signals 
QUEUE _DEPTH_NOT_ REACHED. 


If a schedule queue depth is not defined, this machine signals 
NO_QUEUE_DEPTH_SET. 


This is an undefined protocol machine. It starts a transaction program. This 
function is embedded in the local execution environment of DS. 


The server manager controls access to the server object. All the machines 
needing access to the server object send signals representing server verbs to 
the server manager, and receive back an indication of the success or failure of 
the requested operation. The signals back may or may not have data associ- 
ated with them. The signals to the server manager have the server object 
information from the distribution. The name of the server is assumed to be 
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passed to the server manager along with the other associated parameters. The 
input signals are handled as follows: 


e INCREMENT OBJ_LOCK 


The server manager checks to determine whether a server object exists. If 
not, the server manager signals back OK. If a server object does exist, the 
server manager inspects the DS or agent (as appropriate) lock count, and if 
it is O, issues an Assign Read_Access server verb and sets the appropriate 
lock count to 1. Otherwise, it simply increments the DS or agent (as 
requested) lock count. The server manager then reports the results of the 
operations and returns parameters to the signalling machine. The state of 
the server object after the successful completion of the verb is read-locked. 


e READ 


The server manager issues the Read verb or an Initiate_Read/Read 
sequence of verbs (as appropriate) with the supplied parameters to the 
appropriate server. The server manager reports the results and returns 
parameters to the calling machine. The possible return codes are 
OBJECT OK (indicating the successful completion of the verb and return of 
server object data), NO OBJECT EXISTS (indicating that the distribution has 
no server object), OBJECT_EOD undicaung.t that no more server object data 
remains) and OBJECT _NOT_OK. 


The server return code of SPECIFIC_SERVER_EXCEPTION is mapped to 
OBJECT NOT_OK. In this case, distribution reports are suppressed, and 
any specific server reports supplied by the server are delivered to the 
origin agent. 


e WRITE 


The server manager issues the Write verb or an Initiate_Write/Write 
sequence of verbs with the supplied parameters to the appropriate server. 
The server manager reports the results and returns parameters to the sig- 
nalling machine. The possible return coages are OBJECT OK, 

OBJECT _NOT_OK and SPECIFIC_SERVER_EXCEPTION. 


e TERMINATE _READ 


The server manager issues the Terminate_Read verb (if appropriate) with 
the parameters supplied with the signal into the server manager machine. 
The server manager reports the results and returns parameters to the sig- 
nalling machine. The possible return codes are OBJECT OK and 

OBJECT NOT_OK. If no server object exists, or if no Initiate_Read verb was 
issued for the server object previously, the Terminate_Read verb is sup- 
pressed and the SERVER_MGR simply returns OBJECT OK. 


e TERMINATE_RESTARTABILITY 


The server manager issues the Terminate_Restartability verb (if appro- 
priate) with the parameters supplied with the signal into the server 
manager machine. The server manager reports the results and returns 
parameters to the signalling machine. The possible return codes are 
OBJECT_OK and OBJECT NOT_OK. If no server object exists, or if restart 
capability was not specified in the Initiate_Read or Initiate_Write verb, the 
Terminate_Restartability verb is suppressed and the SERVER_MGR simply 
returns OBJECT_OK. 
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¢ TERMINATE_WRITE 


The server manager issues the Terminate_Write verb (if appropriate) with 
the parameters supplied with the signal into the server manager machine. 
The server will assign read access to DS upon completion of the | 
Terminate_Write, and server manager sets the DS lock count to 1. The 
server manager reports the results and returns parameters to the signalling 
machine. The possible return codes are OBJECT _OK and 

OBJECT _NOT_OK. If no server object exists, or if no Initiate_Write verb was 
issued for the server object previously, the Terminate_Write verb is sup- 
pressed and the SERVER_MGR simply returns OBJECT_OK. 


e DECREMENT_OBJ_LOCK 


The server manager checks the server object information in the distribution 
to determine if a server object exists. If no server object exists, the server 
manager signals back OK. 


If a server object exists, the server manager decrements the DS or agent 
(as appropriate) lock count. If the agent lock count is decremented from 1 
to 0, the server manager issues a Release Read Access verb for the agent. 
If, after the decrementing operation, both the DS and agent lock counts are 
0, the server manager issues a Release_Read_Access verb for DS. The 
server manager then reports the results, and returns parameters to the sig- 
nalling machine. 


¢ BACKOUT 


This signal causes SERVER_MGR to issue a Backout_Server_Object server 
verb. Any returned server report is passed back to the caller. OBJECT_OK 
is returned to the caller in any event. 


¢ QUERY_LAST BYTE_RCVD 


This signal causes SERVER_MGR to issue a Query_Last_Byte_Received 
server verb. The byte count returned by the server is passed back to the 
caller to be included in a CRMU(SUSPENDED). OBJECT_OK or 

OBJECT _NOT_OK is returned, as appropriate. 


Output signals 
¢ OBJECT_OK 
The requested operation was performed successfully, or was not necessary. 
e NO_OBJECT_EXISTS | 


This return code indicates that a READ operation has been issued for a dis- 
tribution which contains no server object. This condition will be detected on 
the initial READ for the distribution. 


¢ OBJECT _EOD 


This return code indicates that a Read verb has encountered the ”“end-of- 
data” condition for the server object. Previous Read verbs have already 
exhausted the server object data, and no data remains to be returned to the 
caller when this condition is detected. 
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QUEUE_MGR 


¢ OBJECT NOT OK 


The requested operation failed. On READ operations, 
SPECIFIC_SERVER_EXCEPTION is mapped to this return code. In this case, dis- 
tribution reports are suppressed, and any specific server reports supplied 
by the server are delivered to the origin agent. 


¢ SPECIFIC_SERVER_EXCEPTION 


This is returned only on WRITE operations. The specific server accepted 
the server object before receiving the complete object. 


The QUEUE _MGR provides a common service for all the FSMs in the DSU for 
controlling the router-director queue, the local delivery queues, the next-DSU 
queues, the control MU queue, and the mid-MU restart queue. It also incre- 
ments the queue depth (a scheduling mechanism) for each of the next-DSU 
queues when an element is enqueued, and resets the queue depth when the 
queue is empty or held. It takes as input queue-operation signals and associ- 
ated supplied parameters, and returns the success or failure of the operation as 
well as the associated output parameters. The input signals are: 


e HOLD 


The queue manager holds the designated queues, so that subsequent 
READQ signals return QUEUE_EMPTY. The fype of hold to be set must be 
supplied: 


-— Exception-holds are set automatically when a retriable exception is 
encountered, and cleared automatically by the first READQ of a new 
instance of DS_Send. 


— Operator-holds are set and cleared only by explicit operator action. 


If the HOLD is successful, QUEUE_OK is returned; if the HOLD fails, 
QUEUE _NOT_OK is returned. 


« DEQ 


The queue manager removes the distribution from the queue and returns it 
to the machine issuing the signal. The data accompanying this signal 
includes the name of the queue, and the identifier of the distribution to be 
dequeued. If the distribution is dequeued successfully, QUEUE OK is 
returned; if the dequeueing operation fails, QUEUE _NOT_OK is returned. 


° WRITEQ 


The queue manager places the distribution at the end of the queue. The 
data accompanying this signal includes the name of the queue and the 
entry to be enqueued. This function marks the queue entry (the distrib- 
ution) as being in-use. The distribution cannot be read when it is marked 
in-use. If the distribution is successfully written to the queue, QUEUE OK is 
returned; if the write operation fails, QUEUE NOT_OK is returned. 
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e READQ 


The queue manager reads the distribution on the queue, but does not 
remove it from the queue. The data accompanying this signal include the 
name of the queue and the identifier of the distribution, or an indication that 
the “next available” distribution is to be read. The first READQ for the 
next-DSU queues issued by DS_Send will clear an exception-hold indicator, 
if itis set on. On subsequent READQ signals, QUEUE_EMPTY is returned if 
either the exception- or operator-hold indicator is on. 


If the “next available” distribution is to be read, the distributions available 
for transmission to the partner are scanned, and the highest priority distrib- 
ution is chosen. If no available distributions are on the queue (the queue 
may be empty, all distributions may be in-use, or the queue may be held), 
READQ returns QUEUE EMPTY. 


lf the request specifies a particular distribution, but the distribution’s in-use 
mark is set, QUEUE ENTRY_IN_USE is returned unless suspend is specified. 
A caller specifying a specific distribution with suspend is suspended for a 
period of time if the distribution is in-use. If the distribution becomes avail- 
able while the caller is suspended, the caller’s READQ completes success- 
fully; if the distribution does not become available, QUEUE _ENTRY_IN_ USE 
is returned. 


Otherwise, the output of this function is the information from the distribution 
and a return code of QUEUE_OK. This function marks the queue entry (the 
distribution) as being in-use. If the operation fails, QUEUE NOT_OK is 
returned. 


e RELEASEQ 
The queue manager removes the in-use mark from the distribution. The 
data accompanying this signal includes the queue name and the identifier 
of the distribution. If the in-use mark is successfully removed, QUEUE _OK 
is returned; if not, QUEUE _NOT_OK is returned. 

Output signals 

e QUEUE OK 
The requested operation was performed successfully. 

e QUEUE NOT_OK 


This return code indicates that the requested operation failed because of an 
exception condition in the queue service. 


© QUEUE _ENTRY_IN USE 


This return code indicates that a particular distribution could not be read 
because its in-use mark is set. 


° QUEUE _EMPTY 


This return code indicates that no queue entry satisfying the READQ’s 
search criteria can be found. 
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BUILDER 
The transport services MU builder encodes FS1 and FS2 DMUs, REMUs, 
SEMUs, CRMUs, CQMUs and PRMUs. The builder is signalled by: 


¢ DS SEND BUILD SEND _DMU and DS SEND SEND DMU_NO MU _ID with 
BUILD and END OBJECT to build FS2 DMUs. 


¢ DS SEND CLEANUP EXCEPT and DS SEND_ISSUE_SEMU_ON CRMU to 
build FS2 SEMUs. 


* DS_RCV_SEND ERR_REMU, DS RCV SEND ERR _SUSP_TERM_REMU and 
DS_RCV_REMU_SUSP_TERM to build FS2 REMUs. 


* DS _RCV_SEND ERR_CRMU, DS RCV_SEMU_HANDLER, 
DS _RCV_ENQ SCHED and DS_RCV_CQMU_HANDLER to build FS2 CRMUs. 


¢ DS_SEND_RELEASE_ON_CRMU to build FS2 CQMUs. 


¢ DS SEND RETRY_ON REMU, DS _SEND_TERMINATE_DIST, 
DS_SEND_PURGE_ON_CRMU and DS_SEND_RETRY_ON_CRMU to build FS2 
PRMUs. 


e FSM_DIST_ENCODE CONTROL with BUILD and END OBJECT to build FS1 
DMUs. 


e FSM_SEMU_ENCODE, with BUILD_SEMU to build FS1 SEMUs. 

¢ FSM_REMU ENCODE with BUILD REMU to build FS1 REMUs. 
The builder encodes the MUs as defined in Appendix G. To indicate that the 
builder has successfully encoded a portion of the MU, this machine signals 
BUILD_OK. To indicate that the next portion of the MU to be sent on the con- 
versation contains part of the data server object, this machine signals 


BUILD _OK_GET_OBJECT. When the builder has completed the encoding of an 
MU, this machine signals BUILD_COMPLETE. 


The information needed to encode the MUs (for example, buffer of data from 
reading the server object, exception information for either the SEMU or the 
REMU) is passed to the builder. 


Exceptions from the builder cause the signal BUILD_NOT_OK and information 
about the exception to be returned to the caller. 


PARSER 
The transport services MU parser decodes FS1 and FS2 DMUs, REMUs, CRMUs, 
CQMUs and PRMUs. The parser is signalled by: 


e DS RCV_RECEIVE_DMU and DS_RCV_RECEIVE_DMU_NO_MU_ID with 
PARSE to decode FS2 DMUs. 


¢ DS_SEND_RECEIVING with PARSE to decode FS2 CRMUs and REMUs. 
¢ PREPARSER to decode FS2 CQMUs, PRMUs and SEMUs. 

e FSM_DIST_DECODE_CONTROL with DECODE to decode FS1 DMUs. 

e FSM_SEMU_DECODE with PARSE_SEMU to decode FS1 SEMUs. 

e FSM_REMU_DECODE with DECODE_REMU to decode FS1 REMUs. 
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The parser decodes the MUs as defined in Appendix G and builds a control 
block containing the MU’s information. The parser may return the following 
return codes: | 


° PARSE_OK 


The MU passed to the parser is a DMU, and the parser successfully 
decoded the portion of the DMU passed to it. 


¢ PARSE_OK_ OBJECT 


The portion of the DMU passed to the parser contains a portion of the 
server object, which should be passed to the server. 


e PARSE_COMPLETE 
The DMU passed to the parser was successfully and completely decoded. 
e PARSE_NOT_OK 
An exception was detected while decoding the MU. 
e CRMU 
The MU passed to the parser is a CRMU, which was successfully parsed. 
e REMU 


The MU passed to the parser is a REMU, which was successfully parsed. 
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API 
APPC 
BCPB 


CGCSGID 


CMU 
CQMU 
CRMU 
DCMU 
DEN 
DGN 
DIA 
DMU 
DRMU 
DS 
DSU 
DTM 
DTMU 
ECS 
FIFO 
FSM 
FS1 
FS2 
GEN 
GMT 
IRN 
LU 

MB 
MU 
NAU 
PB 

PC 
PCIRN 
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Application Program Interface 
Advanced Program-to-Program Communication 
Basic Conversation Protocol Boundary 
Coded Graphic Character Set Global Identifier 
Control Message Unit 

Completion Query Message Unit 
Completion Report Message Unit 
Distribution Continuation Message Unit 
Distribution Element Name 

Distribution Group Name 

Document Interchange Architecture 
Distribution Message Unit 

Distribution Report Message Unit 
Distribution Services 

Distribution Service Unit 

Date/Time 

Distribution Transport Message Unit 
Enhanced Character String 

First-In, First-Out 

Finite-State Machine 

Format Set 1 

Format Set 2 

General Server 

Greenwich Mean Time 

(Path Control) Intermediate Routing Node 
Logical Unit 

Megabytes 

Message Unit 

Network Addressable Unit 

Protocol Boundary 

Path Control 


Path Control Intermediate Routing Node 
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PRMU 
PS 
RBP 
RAMU 
REMU 
REN 
RGN 
RRMU 
SEMU 
SNA 
SNACR 
SNA/DS 
TP 
TPN 
TPF 
UPM 
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Purge Report Message Unit 
Presentation Services 

Restart Byte Position 

Reset Accepted Message Unit 
Receiver Exception Message Unit 
Routing Element Name 

Routing Group Name 

Reset Request Message Unit 
Sender Exception Message Unit 
Systems Network Architecture 
SNA Condition Report 
SNA/Distribution Services 
Transaction Program 
Transaction Program Name 
Transmission Priority Field 


Undefined Protocol Machine 


Appendix B. Introduction to Finite-State Machines 


Introduction to FSMs 


A finite-state machine (FSM) is represented as a state-transition matrix con- 
sisting of a set of states, a set of input signals, a set of output codes, a next 
State function, and an output function. The states are a small number of named 
values (the state names). An FSM’s execution depends on a combination of 
processing and memory, where the memory consists of one of the states of the 
FSM. The processing is defined by the state-transition matrix, each cell {row- 
column intersection) of which shows the new state of the FSM, and the output 
code to be executed. Within this matrix, each state is given a number, as well 
as a name, for notational convenience. 


The syntax of the state-transition matrix is shown in Figure 53 on page 364. 
The column headings give the FSM state names, while the row headings give 
the input signals. The matrix cells define the state transitions and output codes 
when the FSM is in the given states and receives the given input signals. 


If the next-state indicator is a number n, the FSM enters state n. If the next- 
state indicator is a cannot-occur indicator (/), this is an execution-time error: 
calls of the FSM cannot encounter this indicator because previous logic has fil- 
tered out the input for that state of the FSM. If the next-state indicator is a no- 
state-change indicator (-), the FSM remains in its same state. 


in the state-transition matrix, double horizontal lines are used to group input 
lines together to improve readability. Their location has no bearing on the FSM 
function. For compactness, mnemonic abbreviations are used in the matrices. 


An FSM comes into existence initialized to state 1. If another state is to be the 
initial state, the FSM is initialized explicitly by signalling the FSM with an appro- 
priate input signal. 


An FSM always has at least one state and one input signal. Consequently, the 


state-transition matrix always has at least one row and one column. Output 
codes may be absent entirely. 
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fname 


Output logic statements 
Output logic statements 
Legend: 
fname = FSM name 
sna = state name 
snu = state number 
ic = input signal name 
ac = action code 
oc = output code 
An action code (ac) has the following possible syntax: 


n normal state transition to state n (corresponding to some snu) 


noc normal state transition to state n (corresponding to some snu) 
and execution of the function identified by oc 


- same-state transition (remain in the same state) 


-o¢  same-state transition (remain in the same state) 
and execution of the function identified by oc 


/ “cannot occur” condition, no state change 


Figure 53. Syntax of an FSM State-Transition Matrix and Output Codes 
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Implementation Alternatives 


Because an architecture can be implemented in equipment of different sizes to 
serve various application purposes, it is not unusual for a given implementation 
to choose to implement less than the complete architecture. Certain functions 

can be omitted without harming the overall network; others cannot. Therefore, 

the architecture defines the rules under which implementations may choose to 

omit functions. 


The effect of these choices upon the total size of the implementation can be 
very significant. The smallest compliant implementation might be about 1/50 
the size of the largest. 


References to these choices will be found in other parts of this document. 
Anyone interested only in a general understanding of the architecture can 
safely ignore such references and need not read this appendix. Anyone inter- 
ested in designing an implementation of the architecture should read and thor- 
oughly understand this appendix. 


Categories of Choices 


There are six categories of choices. In decreasing order of importance, they 
are: 


. Protocol boundary exposure 
. Role 

. Base and option sets 

. Electives 


. Specializations 


oOo om @d %m©™ = 


. Optimizations (no observable function omitted) 


Every implementation makes choices in each of the categories. A choice made 
in one category, or a combination of choices in several categories, may often 
restrict the possible choices in other categories. 


Implementations may have an internal structure that differs from the architec- 
ture model. Provided this choice of internal structure has no externally per- 
ceived effects, it is not subject to architectural compliance rules and is 
considered an optimization. Some optimizations that are especially appropriate 
in highly specialized implementations are mentioned in this document. 
However, they are intended only as helpful suggestions. 
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Protocol Boundary Exposure 


The Choice of Open or Closed 
Implementations have either open or closed protocol boundaries (PBs). Typi- 
cally, an open PB is implemented as an application program interface (API). 
Alternatively, some PB functions can be implemented as an end-user 
interface--in other words, in the form of screens and keyboard inputs. The 
latter form of PB is suitable for operations verbs but is not suitable for 
Send_Distribution or Receive_Distribution: these verbs require sequence 
numbers and may contain encoded agent objects. 


Open agent and server protocol boundaries allow any agents and servers to 
interact with DS. Assuming that the user, agent, and server names are known 
by the DS network in one or more DSUs, any distribution request, within the 
base set of functions described below, will be successfully serviced. 


Implementations not offering an open protocol boundary may, depending on 
other choices, find their implementation responsibilities significantly reduced. 
Such implementations have a closed protocol boundary, since they provide only 
a restricted set of services to restricted sets of users, agents, and servers. 


The operations protocol boundary cannot be closed. Whatever operations func- 
tions are supported by an implementation are available, by one means or 
another, to the operations and maintenance staff serving the network as a 
whole. For example, a central operator at one DSU might obtain operations 
information from another DSU by telephoning the operator at that DSU who 
obtains the desired information by means of an interactive end-user interface. 
Unattended DSUs may have remote interactive end-user interfaces, or if they 
are expected to require limited operational interaction, they may use simpler 
remote techniques such as downloading their software or microcode and 
retrieving their logs and dumps. In other words, an open operations PB means 
that an operator, not necessarily at the DSU, must be able to control the DSU’s 
operation by means that are appropriate for the frequency of required inter- 
ventions. 


The agent protocol boundary and the server protocol boundary are either both 
open or both closed. 


Rules for Closed Protocol Boundaries 
Implementations with closed protocol boundaries: 


e May limit their originating and delivering functions. 


— May restrict their set of users to 0. 

— May restrict their set of agents to 1. 

— May restrict the services provided to only those needed by the 
restricted set of users or agents. 

— May restrict their support to only one object, agent, or server. 

— When supporting server objects may restrict their set of server names 
to 1, which could be the default (general server). 
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e Never generate any protocol on behalf of their privately integrated applica- 
tion that an equivalent application using an open protocol boundary cannot 
generate using the defined PB verbs. 


e Are able to exchange traffic with equivalent applications using open pro- 
tocol boundaries, regardless of whether the communication is direct or via 
intermediate DSUs. Closed PB implementations need not implement func- 
tion equivalent to any PB parameters other than whatever is necessary to 
comply with this rule. 


e Are able to exchange traffic with copies of themselves, regardless of 
whether the communication is direct or via intermediate DSUs. 


e Are able to interconnect with any other DS implementation. (Intercon- 
nection to older FS1-only implementations requires support of the FS1 
option subset.) 


— Are able to send MUs requiring base services through any intermediate 
FS2 DSUs. 

— Are able to send MUs requiring optional services through any interme- 
diate FS2 DSUs that provide the required services. 


Rules for Open Protocol Boundaries 
Implementations with open protocol boundaries: 


¢ Support the base semantics of both agent and server PBs. 


e Support, for each optional subset they choose to implement, whatever addi- 
tional PB semantics the subset requires. 


¢ Do not restrict their originating and delivering function. 


— Support as many users as their largest equipment configuration can 
reasonably support. 

— Support a variety of architecturally-defined and installation-defined 
agents. 

— Support a variety of architecturally-defined and installation-defined 
servers. 

— Contain installation-defined tables or lists against which the destination 
agent and destination server names in the incoming MU can be com- 
pared. 

— Originate or accept for delivery any distribution requiring services 
defined in the base or any chosen option sets that specifies user, agent, 
and server names defined for the DSU. 


e Are able to interconnect with any other DS implementation. (Intercon- 
nection to older FS1-only implementations requires support of the FS‘ 
option subset.) 
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Role 


Implementations may limit their DSUs to certain roles only. The choices are: 


1. 
2. 
3. 
4. 
5. 


Origin-only: closed PB only 

Destination-only: closed PB only 

Origin and Destination (End-only): open or closed PB 
Intermediate-only: closed PB (no application program interface at all) 


All roles: open or closed PB 


Combinations such as origin and intermediate are possible but too unlikely to 
justify discussion. The end-only and all-roles combinations are the most usual. 
The rules for the elementary roles are given below. Rules for combinations are 
the union of the rules for the appropriate elementary roles. 


Rules for Origin Role 


Origin role implementations with a closed PB and appropriately specialized 
applications or devices, such as a card reader, may restrict themselves to 
only originating distributions. 


Implementations that provide an open protocol boundary are able to 
process distribution-originating verbs passed across the agent PB. Open 
PB implementations also support the receiving verbs and, therefore, cannot 
be origin-only. 


Implementations with closed protocol boundaries may limit the types of 
traffic they originate, but they never generate MUs that other DSUs cannot 
process normally. 


Implementations are able to generate distribution reports, unless they have 
a closed PB and are specialized in traffic that never requests reporting. 


Rules for Destination Role 


Destination role implementations with a closed PB and appropriately spe- 
cialized applications or devices, such as a line printer, may restrict them- 
selves to serving only as destinations. 


Implementations that provide an open protocol boundary are able to 
process distribution-delivery verbs passed across the agent PB. Open PB 
implementations also support the sending verbs and therefore cannot be 
destination-only. 


An implementation in the destination role accepts any MU requiring base or 
selected option set function that specifies a known destination agent and 
server, stores the object using the specified server, and delivers the distrib- 
ution to the specified agent by making an entry in the appropriate queue. 
Then, if possible, it initiates the specified destination agent. 


Implementations in the destination role reject any MUs containing unrecog- 
nized structures within parents that preclude them but accept and ignore 
unrecognized structures within parents that allow them. 
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e Implementations in the destination role reject MUs containing any flag bits 
they don’t understand in the first two bytes of the distribution flags. 


¢ Implementations in the destination role reject MUs that do not meet the 
minimum parsing checks. 


e Implementations in the destination role may reject MUs that do not meet 
optional parsing checks. 


e Implementations in the destination role reject MUs containing any service 
parameters they don’t understand. 


e Implementations in the destination role process the distribution in a manner 
consistent with the specified service parameters. 


¢ Implementations are able to generate distribution reports, unless they have 
a closed PB and are specialized in traffic that never requests reporting. 


Rules for Intermediate-only Role 
e Implementations in the intermediate role completely receive an MU, and 
depending on the integrity and protection specified for the distribution, store 
it and any objects it may contain before forwarding it. 


e When an intermediate node receives a multiple-destination distribution 
whose destinations are reached over different outgoing connections, imple- 
mentations generate multiple outgoing MUs, each containing byte-perfect 
copies of the objects and a portion of the received destination list. 


e Implementations in the intermediate role reject MUs that do not meet the 
minimum parsing checks. 


e Implementations in the intermediate role may reject MUs that do not meet 
optional parsing checks. 


e Implementations in the intermediate role reject MUs specifying service 
parameters that they cannot provide. 


e Implementations in the intermediate role process the distribution in a 
manner consistent with the specified service parameters. 


e Implementations in the intermediate role pass through, unchanged, any 
unrecognized structures occurring within parent structures where unrecog- 
nized children are allowed. 


e Implementations in the intermediate role reject MUs containing non- 
understood flag bits in the first byte of the distribution flags. 


¢ Implementations are able to generate distribution reports, unless they have 
a closed PB and are specialized in traffic that never requests reporting. 
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Base and Option Sets of Functions 


In DS, as in other architectures, the notion exists of a mandatory or base set of 
the functions that all implementations support except insofar as their choices of 
PB exposure, role, and specialization may have made the functions inappli- 
cable. Individual functions not included in the base set are options that imple- 
mentations may select, but not on an individual function-by-function basis. The 
number of optional functions is so large that if implementations were free to 
select them individually, it is unlikely that any two implementations would select 
exactly the same set. As a result, connectivity between them would be 
impaired or impossible. To avoid this, the optional functions are grouped into 
named sets. 


Base and Option Set Diagram 
A convenient way to represent the option sets is with a diagram (see 
Figure 54). The complete set of functions described by the architecture is the 
union of all the rectangles in the diagram. The option sets that an implementa- 
tion may omit are represented by smaller rectangles inside the full diagram. 
An option set that is located underneath another set is a prerequisite for the 
upper set and cannot be omitted unless all the sets above it are also omitted. 


FORMAT SET 1 
SUPPORT 
Option Set 


ENHANCED |SECURITY 


BASE FUNCTION 
Mandatory Set 


Figure 54, Base and Option Set Diagram 


General Rules for Base and Option Sets 
1. DS implementations include all the functions defined in the base that apply 
to their choices of role, PB exposure, and specialization. 


2. Each option set must be implemented completely. 


3. Implementations never provide a function defined in a set in some way dif- 
ferent from that defined by DS. Implementations always provide that func- 
tion and all other functions in the set only as specified by the architecture. 


Summaries of the major features of each set follow. 
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Rules for the Base Set 


Base PB Verbs 
« Implementations with open PBs accept both high- and basic-integrity verb 
sequences for sending and receiving distributions using the following verbs: 


— $end_Distribution 

— Query_Distribution Sending 

— Sending Sequence_Completed 
— Receive_Distribution 

— Receiving Sequence_Completed 


e Implementations with open PBs receive reports from either the distribution 
service or from the server using the following verbs: 


— Receive_Distribution_Report 
— Obtain _Local_Server_Report 


e Implementations with open PBs interact with the server using the following 
verbs: 


— Assign _Read_Access 
— Release_Read_Access 
— Initiate Read 

— Read 

— Terminate_Read 

— Initiate_Write 

— Write 

— Terminate_Write 

— Backout_Server_Object 


e Implementations with open PBs perform the following checks on each verb 
at the protocol boundary when originating distributions: 


— All structures in the verb are checked for consistency with the length, 
contents, and conditions of presence as defined in Appendix F. 


— If an origin user is specified, the DSU checks that that user is local. 


— The destination list is examined and duplicate destinations are elimi- 
nated. 


— If reporting is requested, the DSU determines whether or not reports 
will be returned to it, and if so, checks that the report-to user and agent 
are local. If not, the DSU confirms that its local directory and routing 
table contain entries that allow it to honor its reporting responsibilities. 


— Ifa specific server is specified, the DSU checks that the server exists 
locally. 


Base Service Parameters 
Implementations are able to receive MUs and accept PB requests (for open PB 
implementations) with, and provide the required services for, the following 
service parameter specifications: 


1. priority: REQUIRE_LEVEL_GE for any of 18 levels: FAST, CONTROL, DATA_16, ..., 
DATA_1. When sending on a given connection, implementations send all dis- 
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tributions of priority n before sending any of priority n - 1 (unless they have 
elected to fold the data priorities as described in “Electives” on page 377). 


2. protection: 


€@. REQUIRE_LEVEL_GE LEVEL2. Implementations store both the DS control 
information and the objects on non-volatile storage. 

b. REQUIRE_LEVEL_GE LEVEL1. Implementations may provide either LEVEL‘ or 
LEVEL2 protection. 


3. Capacity: 


a. REQUIRE_LEVEL_GE ZERO. Implementations are able to selectively route 
based on this capacity service level. Network administrators may 
define DSUs that will not accept distributions with server objects pro- 
vided that the routing tables of the surrounding DSUs are appropriately 
defined so that only zero-capacity distributions are routed to them. 

b. REQUIRE_LEVEL_GE 1MB, 4MB, 16MB. Base implementations in the interme- 
diate role can, in normal operation, store and forward server objects of 
up to 16MB in size. Base implementations can selectively route on any 
of the three nonzero capacity service levels. 


Network administrators may define DSUs that will not accept distrib- 
utions with server objects larger than either of the lower levels, 1MB or 
4MB. If so, they define the routing tables of the surrounding DSUs so 
that distributions are routed appropriately. 


Implementations may optimize their storage management on the 
assumption that the server object will not exceed the specified size. At 
the PB the server object size is validated against the capacity 
requested only if server_object_byte_count is supplied. When receiving 
an MU, if the receiving process determines that the server object size 
exceeds the capacity requested, the DSU may either abort the transfer 
process at that point or attempt to receive it despite its size. If the dis- 
tribution is successfully received, the capacity service parameter is set 
to the appropriate higher level before the distribution is forwarded. 


4. security: REQUIRE_LEVEL_GE LEVEL1. LEVEL1 security requires no special action. 


Base Reporting 
Implementations are able to honor the reporting requirements for exception 
reporting. 


Base Encoding Support 
Implementations are able to send and receive the following types of FS2 
message units: 


¢ DTMU 
e DCMU, except: 

— When sending, the restart position needs to be only the beginning of the 
LLID following the last LLID received (sender restarting within an object 
is an elective--Sender Byte-Count Restart elective). 

— When receiving, DCMUs that restart in mid-object may be rejected 
(receiver restarting within an object is an elective--Receiver Byte-Count 
Restart elective). 

e DRMU 
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¢ CRMU, except that byte-position information need not be generated and 
may be ignored on receipt. 
¢ CQMU 
e PRMU 
SEMU 
e REMU 
RRMU 
RAMU 


Base Scheduling 
¢ Implementations are able, subject to possible scheduling constraints, to ini- 
tiate the SNA service transaction programs that perform the sending when- 
ever distributions are ready to be sent. 


¢ Implementations allow other DSUs to initiate either their receiving or 
sending SNA service transaction programs (DS_Receive or DS_Send) by 
means of an LU 6.2 Attach FM header. 


Base Protocol 
e Before sending any DMUs on a newly defined or discovered connection, the 
partner DSUs initialize MU-ID registries for the connection using an 
RRMU-RAMU exchange. On existing connections, RRMU-RAMU exchanges 
should be performed at least monthly. 


e Each implementation supports the base FS2 protocol and gracefully toler- 
ates any elective choices that differ from its own. 


e Successful FS2 high-integrity transfers are completed by a CRMU-PRMU 
exchange. 


e Unsuccessful transfers detected by the sender are indicated by the sender 
with a Send_Error followed by a SEMU. 


¢ Unsuccessful transfers detected by the receiver are indicated by the 
receiver with a Send Error followed by a REMU. 


e Implementations support Mid-MU Restart at any of the highest-level LLID 
boundaries after the Dest_List, including LLID structures they do not recog- 
nize. 


Base Routing and Directing 
e Implementations maintain queues of traffic and requests whenever 
resources are busy. When resources are unavailable, implementations are 
able to either queue the traffic or take other action appropriate to the type 
of traffic. 


e Implementations (except end-only, closed PB ones) either provide or are 
provided access to a user directory. This implies a tabular directory in 
which any DGN.DEN can be associated with any RGN.REN or error indi- 
cator. It also implies that DGN.* or *.* can be associated with any RGN.REN 
or error indicator. 


« Re-direction Responsibilities 


Base Implementations (except end-only, closed PB ones): 
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— Change the destination DSU for any user destination found not to be 
local to the re-directing DSU. 


— Do not change the destination DSU for any node-destinations. A node- 
destination is identified by a destination list entry that contains no 
users. 


— Support the Intervention List. When a distribution is received containing 
any DSU name that matches an entry in the intervention list, the 
directing process is invoked. 


Base Operations 
Implementations support the following connection control verbs: 


e Start_Connection 

e Reset_MU_ID_Registry 
e List_Control MU Queue 
« Terminate_Connection 


Implementations provide the operator with the functions defined for the fol- 
lowing distribution control verbs: 


e List_Queues Containing Distribution 
e List_Queue_Entries 

e Get_Distribution_Info 

e Purge Queue Entry 

¢ Hold_Distribution_Copy 

e Release_Distribution_Copy 


Implementations also support the following operations verbs that list, add, and 
remove DSU operations information: 


e List_DSU_ Data 

e Add DSU_Data 

e Remove_DSU_Data 
e Modify _DSU_ Data 


for the following DSU data structures: 


e Directory 

e Routing table 

¢ Intervention list 

e DSU definition 

e Connection definitions 

e Next-DSU queue definitions 
e Agent list 

e Server list 

e MU_ID registry 


Implementations log exception condition reports in an exception log and 
support the Get_Exception_Log Entry verb to display the logged information. 
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Base Receive-time Checks 
DSUs identify distributions for which they must accept responsibility at the PB 
by the high-integrity parameter and from other DSUs by the presence of the 
MU_!ID. Before a DSU accepts responsibility for a distribution, it checks that it 
either can successfully process it or, if unsuccessful, can report the failure. 


e The encoding structure specifying the types and levels of service required 
must be parsed and compared with the capabilities of the receiving DSU to 
ensure that it is capable of successfully processing the request. 


e The encoding structure specifying the reporting requested must be parsed 
and examined. 


e If reporting is requested, the encoding structures comprising the distribution 
identification, agent correl, and report-to information must be parsed and 
checked for consistency with lengths, contents, and conditions of presence, — 
as defined in Appendix G. 


Base Up-level Co-existence Capabilities 
In order to coexist gracefully in future networks containing DSUs with addi- 
tional, yet-to-be-imagined function, current implementations must provide 
certain toleration features. 


« Implementations must gracefully reject any MU types they do not recognize. 


e Implementations of certain electives, such as byte-count restart, must 
gracefully accept rejections of their elective protocols. 


e Implementations of certain option sets, such as FS1 support, must accept, 
adjust to, and remember rejections received from adjacent DSUs. 


e Implementations must, within limits, gracefully pass through unrecognized 
structures when they are present within a parent defined as capable of con- 
taining unrecognized children. These structures must be passed in 
encodings that are transferred to adjacent DSUs. The limits of number of 
unrecognized children and their total lengths are defined in Appendix F and 
Appendix G. 


e Implementations must ignore unrecognized flags in the distribution flag 
bytes that are not mandatory for the particular role and reject distributions 
that have unrecognized flags in the bytes that are mandatory for the partic- 
ular role. 


Enhanced Character Strings Option Set 
Implementations designed to share a network with FS1-only DSUs, whether or 
not they plan to connect directly to them with the FS1 Support Option Set, may 
choose this option set to ensure any-to-any connectivity. Newly assigned user 
names do not contain any characters outside CGCSGID 01134-00500. 


Implementations supporting this option set have the ability to.send, receive, and 
contain in their internal tables user names comprised of the character set, and 


observing the string conventions, specified in Appendix G. 


For closed protocol] boundary implementations in networks that contain terminal 
devices that cannot support the full character set, the network administrator 
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constrains the choice of characters to those that are common to all terminals in 
the network to allow any-user-to-any-user communication. 


Implementations of this option set also tolerate the enhanced character strings 
in DSU names they receive, routing the MUs and forwarding the DSU names 
unchanged. Except for products with special migration requirements, however, 
DSU names do not use the enhanced character string convention. Newly 
assigned DSU names do not contain characters outside CGCSGID 01134-00500. 


Format Set 1 Support Option Set 
e An implementation supporting this set is able to build MUs in either format 
set. If an adjacent DSU is only FS1-capable, this implementation will build 
FS1 MUs when sending to it, and will parse the FS1 MUs received from it. 


e Implementations of this option set support four DS transport service TPs: 


— FS2 DS Send 
— FS2 DS_ Receive 
— FS1DS_Send 
— FS1DS_ Receive 


e Implementations of this option set can receive a distribution in an FS1 MU 
and forward it in an FS2 MU. Any and all function expressible in an FS1 
MUs can also be conveyed in FS2. (In some reporting cases, one FS‘ 
DRMU will be split into multiple FS2 DRMUs.) 


¢ Implementations of this option set can receive certain FS2 MUs and forward 
them as FS1 MUs. Not all the function expressible in an FS2 MU can be 
expressed in an FS1 MU. The restrictions that apply to distributions that 
must be able to flow through FS1-only DSUs are described in Appendix D. 


e Implementations of this option set support the capacity service parameter 
REQUIRE_SUPPORT_FOR X’FF’ in FS1 MUs. This means they are able to receive 
distributions of any size until their storage resources are overrun. FS2 
capacity service parameters of REQUIRE_LEVEL_GE 16MB (OR 1MB OR 4MB) are 
converted to REQUIRE_SUPPORT_FOR INDEF in FS1 and vice versa. 


Security Option Set | 
Implementations of this option set support distributions that require security, as 
well as those that do not, in DS networks containing a mix of trusted and 
untrusted DSUs. 


Distributions with a security service parameter of REQUIRE_LEVEL_GE LEVEL2 can 
be received and responsibly routed. 


Operator Rerouting Option Set 
This set consists of the function implied by the operations verb 
Reroute_Distribution_Copies. 
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Enhanced Connection Operations Option Set 


Implementations of this set support the following verbs: 


e List_Conversations 

¢ Terminate Conversation 

e List_Distributions Being Sent 

e List_Distributions Being Received 
e List_Adjacent_DSUs 

e List_Connections 


Distribution Logging Option Set 


Electives 


Implementations supporting this set log the distributions that pass through the 
DSU. Each distribution copy is accounted for, either by an entry that consol- 
idates the recording of each copy or by individual MU logs. When distributions 
are logged for cases other than exception conditions, the amount of information 
logged includes whatever is needed to support the Get_Distribution_Log Entry. 
Implementations supporting this set will typically provide the installation with 
some means of limiting the amount of logging performed. 


Certain functions may be implemented in more than one way. In some cases 
the different implementations will result in differences that can be perceived 
outside the DSU. If other implementations, either of DS or of the architectures 
that use it, must make any effort to cope with these differences, then that 
choice is defined in the architecture as an elective. 


Electives have relatively minor effects on partner DSUs. All implementations 
can cope with whichever choices their partners make. If an implementation’s 
choice differs from its partner’s choice, its responsibility is limited to tolerating 
the effect of its partner’s choice. Typically, this means gracefully ignoring 
certain actions the partner DSU takes. If it has made the same choice, its 
responsibility will usually be greater, and the two DSUs may achieve much 
better performance as a result. 


Electives are not optional functions. Optional functions are defined in option 
sets. Electives are choices as to how or when a function is provided. Imple- 
mentations make elective choices for performance or development cost 
reasons. 


All electives are documented in the architecture because they, at least poten- 
tially, affect connectivity. The list of DS electives is as follows. 


Electives within Base Function 


1. Folding data priorities. Implementations may elect to fold the 16 DATA pri- 
orities into 2 groups: 1 through 8, and 9 through 16. The 1 through 8 group 
is called DATALO. When DATALO is used at the PB as a priority service level, 
it is the equivalent of DATA.4. Similarly, 9 through 16 are called DATAHI, the 
equivalent of DATA_12. Within each group, the distributions are sent on a 
first-in, first-out basis. 
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2. Receive-time enhancements. Implementations may elect to perform syntax 
checking, routing, and directing functions at receive time and, when appro- 
priate, report exception conditions to the sending DSU by a REMU. Any 
exception conditions so detected and reported must apply to the entire dis- 
tribution, not to only some of its destinations. Since the sending DSU still 
has responsibility for the distribution, it performs whatever DS reporting is 
required. 


3. Next-DSU queue scheduling. Implementations may elect not to initiate 
sending as soon as a distribution is placed in a next-DSU queue. For 
example, time-of-day or queue depth are criteria that could inhibit the initi- 
ation of sending. Any such inhibiting controls can be removed by operator 
action. 


4. Protocol electives. These electives do not apply to the protocols used in 
the FS1 option set. 


a. Single-session. Implementations may elect to restrict their connections 
to a single session: that is, they may elect not to provide support for 
parallel sessions on that connection. This means that inbound and out- 
bound conversations must serially share the single session. This 
choice is made to reduce development effort at the cost of performance. 
The MU_ID management required for high-integrity traffic is consider- 
ably reduced by the single-session restriction, since only one MU_ID is 
in progress at a time. 


b. Receiver-limited conversation. After receiving the first DTMU on a con- 
versation, the receiver can control how many more, if any, it will accept 
on that conversation. After sending the first DTMU, the sender turns the 

~ conversation around, allowing the receiver to indicate that the conver- 
sation should be ended by sending a CRMU with the 
terminate_conversation flag turned on. This leaves the conversation up, 
so that any outstanding control MUs can be exchanged, after which the 
sender deallocates. If no high-integrity traffic has been received on the 
connection, and therefore no control MUs are being exchanged, the 
receiver may deallocate the conversation directly. 


c. Sender-limited conversation. After the first DMU, if the receiver has not 
specified that the conversation be terminated, the sender has the choice 
of sending another DMU after the PRMU. Ifthe receiver continues to 
accept additional DMUs indefinitely, it becomes the sender’s responsi- 
bility to determine when to end the conversation. Typically, it sends 
until the queue is empty. This is usually the best choice, since starting 
conversations can be time and resource consuming. When the sender 
does decide to end the conversation, it sends any pending control MUs 
and deallocates the conversation. 


d. Receiver byte-count restart 


Implementations of this elective support the byte-count parameters of 
the mid-MU restart CRMU and interact with the storing server with the 
following verbs: 


e Initiate Write with the restartability, restart_ID, and restart_byte 
parameters | : 
e Query_Last_Byte_Received 
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¢ Terminate_Restartability 


Sending implementations that do not support byte-count restart ignore 
the receiver-supplied byte-count and restart at the LLID. 


e. Sender byte-count restart 


Implementations of this elective support the byte-count parameters of 
the MU restart protocols and interact with the fetching server with the 
following verbs. 


e Initiate Read with the restartability, restart_ID, and restart_byte 
parameters 
e Terminate_Restartability 


f. Sending SEMUs for basic-integrity traffic 


When a sender detects an exception condition and aborts the transfer of 
a DMU with a Send _Error, it may or may not choose to follow-up with a 
SEMU. If it does, the SEMU will not contain an MU_ID. Receivers must 
tolerate either choice. 


5. Multiple local-delivery queues. Implementations may elect to have multiple 
local-delivery queues for each user. For example, each combination of user 
and agent can have its own queue. Within a user/agent combination, 
queues could be further differentiated by service parameters, for example, 
by priority. 


6. Selective local-delivery. Usually, the local-delivery queues will be set up to 
accept any service parameters; however, the architecture allows the distrib- 
ution to be rejected because there is no appropriate local-delivery queue 
for a particular service parameter. For example, a distribution specifying 
security: REQUIRE_LEVEL_GE LEVEL2 might not be deliverable to some of its 
user destinations because those users were not cleared for LEVEL2 and 
would not have LEVEL2 local delivery queues. 


7. Informing sender when receiving server terminates before end-of-object. A 
specific server can return object acceptance before the complete server 
object has been delivered. DS Receive can then either continue to receive, 
and discard the server object, or it can send a REMU to DS_Send with a 
retry_action of X’03’. The mid-MU restart CQMU/CRMU exchange will 
cause the distribution to be continued following the server object. 


Electives within the Format Set 1 Support Option Set 


1. LU 6.2 Deallocate (Type = SYNC_LEVEL). FS1 implementations may elect to 
send a separate Confirm flow or combine it with the Deallocate. 
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Specializations 


Depending upon their role and PB choices, implementations can specialize, 
both in the network configuration they support and the types of traffic they can 
handle. The following table illustrates how those choices interact to provide 
greater or lesser potential for specialization. 


This combination of 
choices is precluded 
architecturally 


Specialization can very 
greatly reduce required 
function 


1) Origin-only 


This combination of 
choices is precluded 
architectural ly 


2) Destination- 
only 


Specialization can very 
greatly reduce required 
function 


3) Origin and 
Destination 
(End—only) 


Configuration special— 
ization can reduce 
required function 


Specialization can 
greatly reduce required 
function 


This combination of 
choices is precluded by 
definition 


4) Intermediate— 
only (no local 
applications) 


Application interface is 
eliminated by definition 


5) All Roles No specialization-- 
base (and chosen 
option sets) must be 


fully implemented 


Traffic specialization 
can reduce application 
interface requirements 


Figure 55. Effect of PB and Role Choices on Specialization Potential 


Choosing not to provide an open PB ( column A in the table) has the greatest 
effect on specialization potential. It means that the originating and delivery 
interfaces with the applications can be highly specialized, and, for some roles, 
completely omitted. 


Choice of role further affects specialization potential. The following specializa- 
tions are identified by the cells of the table (1A, 3B, etc.) to which they apply. 


¢ No through traffic (1A, 2A, and 3A) 


DSUs that do not have to pass traffic between one connection and another-- 
that is, the intermediate role--or between an open PB and the DS network, 
can specialize in only the types of traffic and services needed by their 
private applications. Properly set up routing tables and correctly specified 
distribution requests ensure that such DSUs will never be sent anything 
outside their speciality. If such a DSU were to receive inappropriate traffic, 
it would reject it, probably at receive time. The following specializations 
derive from the no-through-traffic situation. 


— Single-user traffic (2A, and 3A) 


DSUs that are so configured that they never can have more than one 
local user will never be called upon to perform destination fan-out. 


— No user traffic (1A, 2A, and 3A) 
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Optimizations 


DSUs that are specialized for applications that never specify user desti- 
nations will never have to make reference to a user directory, and 
neither generate nor accept distributions with user names in them. 


— Specialization by service parameters 


Closed PB, end-only DSUs that are specialized in a limited set of 
service types and levels will never be called upon to originate or deliver 
distributions requesting any other services. 


e Closed PB specializations (1A, 2A, 3A, and 5A) 
1. Specialization by server (1A, 2A, 3A, and 5A) 


Closed PB DSUs that are specialized in distributions for only one type of 
specific server will never be called upon to deliver distributions to 
another type of specific server or to the general server. 


2. Distributions with no specific server name (1A, 2A, 3A, and 5A) 


Closed PB, destination DSUs that are specialized in distributions for 
only the general server will never be called upon to deliver distributions 
to any type of specific server. 


3. Distributions with no server objects (1A, 2A, 3A, and 5A) 
4. Specialization by agent (1A, 2A, 3A, and 5A) 


Ciosed PB DSUs that are specialized in distributions for a particular 
agent will never be called upon to deliver distributions to any other 
agent. 


e No routing needed 
— No out-going traffic (2A) 


Destination-only DSUs are never called upon to make outgoing routing 
decisions and therefore do not need to support a routing table. 


— Single connection configuration (1A, 3A, and 3B) 


End-only DSUs that are always so configured that they have only one 
connection will never be called upon to make any route selection, and 
therefore do not need to support a routing table. 


Optimizations can be either perceptible outside the DSU or not. If they are not, 
then, by definition, they cannot be of interest to architecture or other implemen- 
tations. 


If the effects of the optimization are perceptible outside the DSU but other 
implementations need make no effort to cope with those effects, then that 
choice is categorized as an optimization. This contrasts with electives, which 
do impose efforts on other implementations. 


Examples of perceptible optimizations occur most frequently in exception proc- 


essing and reporting. Two implementations could differ in the sequences of 
their checks and, as a result, might report the same condition with different 
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report codes, or, when multiple exceptions were present, might detect and 

report different ones. A common partner could perceive the differences in the 
reports. Provided that the common partner did not have to make any special 
effort to handle either of the two reports, the choice would be categorized as an 
optimization. | 


Sometimes implementations will take different actions in certain exception con- 
ditions. For example, one implementation might deallocate a conversation 
immediately, where another would not. Since the partner has to be able to 
cope with a deallocation anyway, this difference would require no extra effort 
on its part. | 


This does not entitle implementations to be unreasonable. . Field service 
requires report codes that are helpful in diagnosing a problem. Network opera- 
tors require that conversations and sessions are not taken down arbitrarily. 


In summary, optimizations are choices made by an implementation that do not 
affect the connectivity of implementations and are therefore not subject to 
precise architectural compliance rules. Therefore, they are not constrained by 
the architecture. 
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Appendix D. FS1/FS2 Coexistence 


General Introduction to the Coexistence Strategy 


The FS1/FS2 coexistence plan is based on a “translation” scheme, whereby a 
distribution encoded initially in one format set may be mapped to the other 
format set. For example, a user on an FS1-only product may send a distribution 
to a user on an FS2-only product. At some DSU along its route, the distribution 
is received in FS1 and forwarded on to the next hop in FS2. The information in 
the distribution is not changed, but its bit-level representation is redefined. 


FS1 products are oriented toward DIA and S/3X Object Distribution agents. 
Implementations with no requirement to connect directly to FS1 products may 
choose to provide only FS2 support. Implementations with a requirement to 
connect directly to FS1 products provide both FS1 and FS2 support. That is, 
new DS implementations supporting DIA or S/3X Object Distribution applica- 
tions with a migration requirement to communicate directly with the FS1 DIA 
and S/3X Object Distribution products will support FS1 as well as FS2. Other 
products need support only FS2. 


Some new FS8S2-only DS implementations may support local DIA or S/3X Object 
Distribution agents. End users on these new implementations can communi- 
cate with end users on FS1-only implementations if an FS1- and FS2-supporting 
DSU is along the distribution’s path, and if the distribution does not exploit any 
FS2-unique function (which cannot be encoded in FS‘). 


To summarize the coexistence plan, certain DSUs will support both FS1 and 
FS2. These DSUs are said to be bilingual. Bilingual DSUs act as gateways 
between FS1-only portions of the DS network and FS2-supporting portions, 
translating between the format sets as necessary. This appendix describes 
how the bilingual DSU determines whether translation is possible, when it is 
required, and how it is accomplished. 


General Actions for Handling Format Set 1 and Format Set 2 Coexistence 
| An FS1-encoding DSU can send and receive only FS1 MUs. Similarly, an 
FS2-encoding DSU can send and receive only FS2 MUs. Bilingual DSUs accept 
both FS1 and FS2 MUs. The “coexistence” problem, therefore, can be reduced 
to a simple question: What does a bilingual DSU do, and how does it know to 
do it? 


The “how” portion of the above question depends on the distribution being 
processed and the capabilities of the DSU to which the distribution is to be 
sent. This topic is discussed in “Determining Partner’s Encoding Level” on_ 
page 385. i 


The “what” portion of the question is discussed in “Detailed Actions for FS1/FS2 
Coexistence” on page 386. The basic approach is a translation scheme, but 
using Format Set 2 whenever possible. Format Set 1 MUs are translated to 
Format Set 2 whenever possible, and Format Set 2 MUs are translated to 
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Format Set 1 as required. For example, if a bilingual DSU receives an FS1 
Dist_MU type TRANSPORT and sends the distribution to another bilingual DSU, it 
uses Format Set 2 flows. 


Coexistence Plan Constraints 


Existing Functions 


Topology 


All restrictions of the coexistence plan are related directly to one or more of the 
following points: 


1. FS2 supports function that cannot be supported in FS1. 


2. Most (if not all) new applications are expected to exploit some FS2-only 
function. 


3. Current FS1 implementations are application-specific, supporting DIA and 
S/3X Object Distribution applications. 


4. New DS implementations are expected to support FS2. 


The coexistence plan is tailored to the use made of FS1 implementations by DIA 
and S/3X Object Distribution applications. Certain architectural features of FS1 
that have not been used by DIA or S$/3X Object Distribution agents (e.g., FS1 
application-report distributions for applications other than DIA) are not sup- 
ported by the coexistence plan. New DIA and S/3X Object Distribution agents 
may exploit FS2-only function, but these new features cannot be translated into 
FS1 and will typically cause distributions exploiting them to be terminated 
should they attempt to enter an FS1 network. 


Since FS1 cannot support all of the function in FS2, new applications cannot, in 
general, communicate over a route containing any FS1-only DSUs. This, com- 
bined with the orientation of the coexistence plan to DIA and S/3X Object Dis- 

tribution leads to the following topologies being supported: 


e FS1 to FS2 
e FS2 to FS1 
e FS1 through FS2 to FS1 


Since FS2 supplies more function than FS1, and since new applications will typi- 
cally exploit this increased function, FS2-to-FS2 traffic must, in general, flow 
over an all-FS2 route. Occasionally, however, a system administrator may wish 
merely to continue using the FS1 applications, and not to use any new applica- 
tions. For such system administrators, the coexistence plan supports the fol- 
lowing topology: 


e FS2 through FS1 to FS2 for existing (FS1) applications using function avail- 
able only in FS1 


Unpredictable results may occur if system administrators configure their 
networks so that new FS2 applications attempt to communicate using an 
FS1 DSU as an intermediate DSU. Usually, distributions exploiting FS2-only 
features cannot be sent through FS1 intermediate DSUs, and will be 
rejected by the bilingual DSU attempting the translation. 
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End-User to End-User Connectivity 
This coexistence plan allows full end-user-to-end-user connectivity for existing 
FS1 applications. An end user supported by an FS1-only, FS2-only, or bilingual 
DSU can communicate with any other end user, without knowledge of the 
encoding-support level of the destination (or any other nonlocal) DSU. The 
encoding-support level of the origin DSU is not affected by (and does not affect) 
the encoding-support level of the destination DSU. 


DSU-to-DSU Connectivity 
A Format Set 1 DSU may connect directly to a Format Set 1 DSU or a bilingual 
DSU. A Format Set 2 DSU may connect directly to a Format Set 2 DSU or a 
bilingual DSU. A bilingual DSU may connect directly to a Format Set 1, Format 
Set 2, or bilingual DSU. 


Determining Partner’s Encoding Level 
Each bilingual DSU must know the encoding-level capabilities of its logically 
adjacent DSUs (i.e., any DSU that can be a “next hop”). This knowledge is kept 
as a data_stream_format field for each next hop, and has a value of FORMAT SET 
1, FORMAT SET 2 Or ERROR. 


The transaction program names for FS2 DS_Send and DS _ Receive are different 
from those for FS1 DS_Send and DS _ Receive. (See “Transaction Program and 
Server Names” on page 631 for the registered values.) A bilingual DSU takes 
the following steps to discover the encoding-support level of each of its logically 
adjacent DSUs. Discovering that the partner is an FS1-only DSU occurs prior to 
the FS2 MU_ID Registry synchronization process, which initializes the DS con- 
nection (see Chapter 2 for details of this synchronization process). 


1. The default value for the data_stream_format field is FORMAT SET 2. 


2. If the value of the data_stream_format field is FORMAT SET 2, a bilingual DSU 
issues an Allocate verb using the Format Set 2 TP names for DS_Send and 
DS_ Receive. 


3. If a verb after the Allocate fails because the attached TP name does not 
exist (return_code = ALLOCATION ERROR, TP NAME NOT RECOGNIZED), the bilin- 
gual DSU resets the data_stream_format field for the partner DSU to FORMAT 
SET 1 and retries the Allocate (see step 4). 


4. If the value of the data_stream_format field is FORMAT SET 1, a bilingual DSU 
issues an Allocate verb using the Format Set 1 TP names for DS_Send and 
DS_ Receive. 


5. If a verb after the Allocate fails because the attached TP name does not 
exist (return Code = ALLOCATION ERROR, TP NAME NOT RECOGNIZED), the bilin- 
gual DSU resets the data_stream_format field to ERROR and notifies the oper- 
ator. 


6. All FORMAT SET 1 values for the data_stream_format variables are period- 
ically reset to FORMAT SET 2. The purpose of resetting these variables is to 
discover whether any logically adjacent DSUs have been upgraded to be 
bilingual. The exact mechanism for resetting these FORMAT SET 1 values is 
left to the discretion of the implementation. A suggested method is to auto- 
matically reset the values once a month (or some other appropriate period). 
Other methods include having the system operator reset the values period- 
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ically, or having the implementation always attempt to allocate a conversa- 
tion using the Format Set 2 TP name (i.e., on each conversation). 


7. If a bilingual DSU is attached by a Format Set 2 TP name, it resets its own 
data_stream_format field for the attaching DSU to FORMAT SET 2. 


8. If a bilingual DSU is attached by a Format Set 1 TP name, it does not reset 
its own data_stream_format field for the attaching DSU to FORMAT SET 1. 
(Simply stated, the FS2 encodings are preferred. News that the partner 
DSU is capable of sending FS2 (see step 7) is sufficient reason to attempt to 
send FS2 to that partner; news that the partner DSU is capable of sending 
FS1 is not a sufficient reason to restrict communication to the partner to 
FS1.) | 


Detailed Actions for FS1/FS2 Coexistence 


Figure 56 on page 388 summarizes the actions of a bilingual DSU for any given 
combination of inputs and next hops. 


Inputs | 
In general, the protocol boundary and the distribution transport sublayer pass 
the same information into and out of the DSU. For example, a DSU may receive 
input from either a Send_Distribution verb or from DS_Receive. This does not 
mean that a single mechanism controls both the Send_Distribution verb and 
DS_Receive, nor does it imply that the same format is used across the agent 
protocol boundary and the LU 6.2 basic conversation protocol boundary. The 
important point is that the information content of the distribution is essentially 
the same, whether it enters the DSU via the Send_Distribution verb or via 
DS_Receive. 


For this discussion, therefore, no distinction is made between data received 
across the agent protocol boundary and data received from a partner DSU. 
Similarly, the data carried out of the DSU by the Receive_Distribution verb and 
the data carried out by the DS_Send process are considered identical. 


The following are the possible inputs to a bilingual DSU: 
¢ Constrained transport information (without DIA report information) 


Constrained transport information is whatever can be held in an FS1 
Dist_MU type TRANSPORT. If a distribution is encoded in FS2, no non-FS1 
features may be exploited: 


— The origin and all destinations of the distribution must be users; the 
report-to destination, if specified, must also be a user. 

— The agent_object must be less than 512 bytes. 

— The dest_agent, if specified, must be DIA or DIASTATUS. 

— Neither the supplemental_dist_info1 field nor the suppiemental_dist_info2 
field may be specified. | 

— The segno field must have a value between 1 and 9999 (inclusive). 
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Next Hop 


Actions 


e Constrained FS2 distribution report information 


This contains only DS report information. Constrained FS2 distribution 
report information is whatever can be held in an FS1 Dist_MU type REPORT 
containing only DS report information. If a distribution is encoded in FS2, 
no non-FS1 features may be exploited: | 


— The reported-on destinations and the report-to destination must be 
users. 

— A reported-on_dest_agent other than DIASTATUS may not be specified. 

— Neither the reported-on_supp dist_infof nor the 
reported-on_supp_dist_info2 field may be specified. 


e Unconstrained FS2 information 


These distributions exploit one or more FS2-only features and therefore 
cannot be encoded in FS1. Attempting to send an unconstrained distrib- 
ution to an FS1 DSU results in the distribution being terminated with an 
exception code of ”“Function conflicts with FS1 encodings” (X’1003 001C’). 


e DIA report 


In FS1, this information is encoded as a Dist_MU type REPORT with only DIA 
report information. If any DS report information were included in the DMU, 
the application (DIA) report information would be discarded. If an FS1 
Dist_MU type REPORT contains only application report information (i.e., no | 
DS report information) and the application is not DIA, the distribution cannot 
be translated into FS2 and is therefore terminated. 


Unlike FS1, FS2 treats agent-to-agent exception flows no differently from any 
other agent-to-agent exchanges, and DIA report information is encoded as a 
constrained DTMU with origin_agent set to DIA and dest_agent set to 
DIASTATUS. 


e FS1 DS report 


This is an FS1 Dist_MU fype REPoRT with DS report information. If applica- 
tion (DIA) report information is also present in the Dist_MU, it is discarded. 


The next hop of a bilingual DSU is either an FS1 DSU or an FS2 DSU. Because 
the default action is to use FS2 encodings, adjacent DSUs that are eon 
appear to be FS2-only DSUs. 


The referenced notes refer to the list below the table. 
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Actions of Bilingual DSU where 


INPUT Next Hop is FS1 Next Hop is FS2 


Constrained Transport Send distribution in FS1 |Send distribution in FS2 
Information (See Note 1) (See Note 5) 

Constrained FS2 DRMU (See Note 2) Send distribution in FS2 
Unconstrained FS2 Terminate distribution Send distribution in FS2 
Information (See Note 3) 

DIA Report (See Note 4) (See Note 6) 

Information 


FS1 DS Report Send distribution in FS1 {|(See Note 7) 


Figure 56. Summary of Detailed Actions of a Bilingual DSU 


Notes: 


1. 


The DSU builds an FS1 Dist_MU type TRANSPORT. If an FS2 DTMU was 
received, then see section “Transport Mapping” on page 389 for the 
structure-by-structure mapping. 


. The DSU builds a single FS1 Dist_MU type REPoRT with gen_SNADS_report. 


See section “DS Report Mapping” on page 391 for further detail. 


. Any unconstrained information in a distribution causes the entire distrib- 


ution copy to be terminated. For example, if a DTMU with multiple destina- 
tions is received and one of the destinations is a node, rather than a user, 
the entire distribution copy is terminated for a// destinations—user and node 
destinations alike. 


. If an FS1 Dist_MU type REPORT with DIA report information is received, the 


DSU simply forwards the DMU on to the next hop. 


If a constrained FS2 DTMU is received, DIA report information is present 
when the destination agent is DIASTATUS. The DSU builds an FS1 Dist_MU 
type REPORT with a DIA report. The DIA report portion of the FS1 
dist_command is taken via simple byte-by-byte copy from the server_object 
of the input FS2 MU. The FS1 MU does not contain a server_object. See 
section “DIA Report Mapping” on page 395 for further detail. 


. The DSU builds an FS2 DTMU. If an FS1 Dist_MU was received, then see 


section “Transport Mapping” on page 389 for the structure-by-structure 
mapping. 


. If an FS2 DTMU is received, the DSU simply forwards the DMU on to the 


next hop, handling this case exactly as it would any other FS2 MU, regard- 
less of the agent specified. 


If an FS1 Dist_MU type REPORT with DIA report information is received, the 
DSU builds an FS2 DTMU specifying the dest_agent as DIASTATUS. The 
portion of the FS1 command containing the DIA report is inserted via simple 
byte-by-byte copy into the server_object. See section “DIA Report 
Mapping” on page 395 for further detail. 
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7. The DSU generates one to four FS2 DRMUs from the FS1 Dist_MU type 
REPORT with DS report (and discards any DIA report information). See 
section “DS Report Mapping” on page 391 for further detail. 


Placement of Conversion Actions 
The placement of the FS1/FS2 mapping functions described below depends on 
the implementation. However, this appendix is written assuming that all 
mapping functions will be performed in the FS1 distribution transport sublayer 
(i.e. the FS1 DS_Send and DS_Receive processes). There is no reason to treat 
any distribution that is received in FS2 and forwarded on to the next hop in FS2 
differently from any other FS2-only distribution. 


Transport Mapping 


All distributions received as FS1 MUs can be built in FS2. Some distributions 
received as FS2 DTMUs, however, may exploit function that cannot be con- 
tained in FS1. Such distributions are termed “unconstrained”; if an attempt is 
made to send them to an FS1-only DSU, they are terminated by the bilingual 
DSU with an SNA_report_code of ”Function conflicts with FS1 encodings” 
(X’1003 001C’). Constrained distributions can be mapped from FS2 to FS1. 


This section gives the structure-by-structure mapping between Format Set 1 and 
Format Set 2 for Transport MUs. Since the supported mappings are reversible, 
Figure 57 suffices for both the FS1 to FS2 and the FS2 to FS1 mappings. 


Transport Atomic Structure Mappings 


FS2 Structure FS1 Structure 


HOP_COUNT HOP_COUNT 

DIST FLAGS DIST FLAGS 
SERVICE_PARMS SERVICE_PARMS 
SERVER_OBJ_BYTE_COUNT SERVER_OBJ_BYTE_COUNT 


ORIGIN. REN ORIGIN REN 
ORIGIN DGN ORIGIN DGN 


REPORT—TO_RGN 

REPORT—TO_REN 

REPORT—TO_DGN REPORT-TO_DGN 
REPORT—TO_DEN REPORT-TO_DEN 
REPORT_SERVICE_PARMS REPORT_SERVICE_PARMS 
REPORT-TO_AGENT REPORT—TO_AGENT 


SERVER_OBJECT SERVER_OBJECT 


Figure 57. FS2 to FS1 Mapping for Transport MUs 
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Notes on execution-time checks and actions, FS2-to-FS1: 


1. Unless otherwise noted, the FS2 structure values are simply copied to their 
FS1 counterparts. 


2. An FS2 DTMU with third-party reporting might specify a report-to_user with 
no report-to_DSU. In this case, the bilingual DSU uses its own DSU name 
as the report-to_DSU for the Format Set 1 MU. 


3. The Format Set 2 agent_correl field will be truncated to 44 bytes, if neces- 
sary. 


4. Unrecognized fields in the command or at the highest level are ignored 
(and discarded). 


5. The exception_report flag of an FS2 DTMU is mapped to the 
correspondingly-named counterpart flag in the FS1 MU. The FS‘ 
distribution_type flag (i.e., TRANSPORT or REPORT) is set based on the 
dest_agent of the Format Set 2 MU; see section “DIA Report Mapping” on 
page 395 for further details. Unused bits in the Format Set 2 dist_flags byte 
4 are ignored (whatever their value). The Format Set 2 dist_flags byte 3, 
bits 0-7, and dist_flags byte 2, bits 1-7 must be 0; otherwise, the distribution 
is terminated. 


6. The FS1 protection service parameter is set to YES. 


7. If the FS2 capacity service parameter is REQUIRE_LEVEL_GE ZERO or the FS2 
priority is greater than DATAI16, then the FS1 capacity is ZERo. Otherwise, 
the FS1 capacity is INDEFINITE. 


8. If the date/time stamp of the DTMU contains GMT plus local offset, the FS1 
MU is given the origin’s “local” time. That is, the local-time offset is added 
to the GMT time to yield the date/time stamp of the FS1 MU. 


9. If a dest_agent of DIA or DIASTATUS is specified, the FS1 agent is DIA. 


Notes on execution-time checks and actions, FS1-to-FS2: 


1. Unless otherwise noted, the FS1 structure values are simply copied to their 
FS2 counterparts. 


2. If the FS1 distribution specifies the capacity service parameter as INDEFINITE, 
the FS2 distribution capacity is set to REQUIRE_LEVEL_GE 16MB. 


3. The server_object_byte_count field, if supplied in the Format Set 1 MU, is 
assumed to be correct and copied to the Format Set 2 MU. No checking is 
performed. 


4. Bits 3-7 of the FS1 dist_flags must be O, or the distribution is terminated. Bit 
2 is ignored, whatever its value. The exception_report flag of a Format Set 
1 DMU is mapped to the correspondingly named counterpart flag in the 
Format Set 2 MU. The Format Set 1 distribution_type flag (i.e., TRANSPORT or 
REPORT) is not carried over directly into the Format Set 2 MU; see section 
“DIA Report Mapping” on page 395 for further details. All unassigned flags 
in the Format Set 2 MU are set to 0. 


5. The server_parms field is not supported in FS2. If it is present in the FS1 
MU, the distribution is terminated. 
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6. The date/time stamp of the FS1 MU is used as the date/time stamp for the 
FS2 MU, and is considered “local” time only (that is, not GMT or 
GMT-plus-offset). 


7. The FS2 distribution is sent with high integrity. 


DS Report Mapping 
This section discusses in detail the Format-Set-1/Format-Set-2 mappings for DS 
reports. 


All distributions received in FS1 can be built in FS2. Distributions received in 
FS2, however, may exploit function that cannot be contained in FS1. In such 
cases, the DSU terminates the distribution and logs the error with the 
SNA_report_code of ’Function conflicts with FS1 encodings” (X’1003 001C’). 


FS2 reports carry both origin and report-to agent information, if both are speci- 
fied. FS1 reports carry only one agent name, and that agent must reflect the 
report-to agent, if specified. Therefore, if a distribution 


1. originates in an FS2 subnet 
2. and exploits the report-to_agent parameter 


3. and has a distribution report that is generated in or passes through an FS1 
subnet 


the report will indicate that the distribution was originated by the report- 
to_agent instead of the true originating agent. 


Also, if a distribution specifies a report-to_user, then the 
reported-on_origin_DSU field will be absent from the FS2 DRMU. 


The mapping between the Format Set 1 Dist_MU type REPORT and the FS2 
DRMU is given in Figure 58 on page 392. 
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DS Report Atomic Structure Mappings 


FS2 Structure FS1 Structure 


HOP_COUNT HOP_COUNT 
SERVICE_PARNS 
REPORT-TO_AGENT 


REPORT-TO_RGN 

REPORT-TO_REN 

REPORT-T0_DGN 

REPORT-TO_DEN Z 
REPORTED-ON_ORIGIN_DGN REPORTED-ON_ORIGIN DGN 
REPORTED-ON_ORIGIN DEN REPORTED-ON_ORIGIN DEN 
REPORTED-ON_SEQNO_DTM REPORTED-ON_SEQNO 
REPORTED-ON SEQNO_DTM REPORTED-ON_DTH 
REPORTED-ON AGENT _CORREL REPORTED-ON_AGENT CORR 
REPORTED-ON_DEST_DGN REPORTED-ON_DEST_DGN 
REPORTED-ON DEST _DEN REPORTED-ON DEST DEN 
RECEIVING RGN DETECTING_RGN 
RECEIVING REN DETECTING REN 
SNA_REPORT_CODE GEN_SNADS COND_CODE 


Figure 58. FS1 to FS2 DS Report Mapping 


Notes on execution-time checks and actions, FS2-to-FS1: 


1. Unless otherwise noted, the FS2 structure values are simply copied to their 
FS1 counterparts. 


2. The destination of the DRMU must be a user rather than a node. If the FS2 
DRMU specifies the report-to_DSU_user as a node, the distribution is termi- 
nated. 


3. Unrecognized fields in the report_command or report_information or at the 
highest level are discarded. 


4. The presence of either the reported-on_supp dist_info? or the 
reported-on_supp_dist_info2 field causes the distribution to be terminated. 


5. The reported-on_origin_RGN and the reported-on_origin_REN parameters 
are discarded. (The reported-on_origin_DGN and repurted-on_origin_DEN 
must be present.) 


6. The origin_seqno parameter is set to X’FOFOFOFO,’ as specified in 
Appendix G. 


7. The dist_flags are set to indicate type (REPORT), exception_report (NO). 


8. The SNA_report_code is mapped to a DS condition code. See Appendix E 
for the exact mappings. 


9. The reported-on_dest_DSU structure is ignored. 


10. The reported-on_agent_corre/ structure is truncated to 44 bytes, if neces- 
sary. 


11. If the reported-on_seqno is greater than 9999, the distribution is terminated. 


12. The protection service parameter is set to YES, and the capacity is set to 
ZERO. 
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13. The reported-on_origin_agent, if present, is ignored. 


Notes on execution-time checks and actions, FS1-to-FS2: 


1. Unless otherwise noted, the FS1 structure values are simply copied to their 
FS2 counterparts. 


2. The origin_user field in the Format Set 1 Dist_MU type REPORT should not be 
present. If present, it is discarded; only the origin_DSU is carried in the FS2 
MU. 


3. Exception reporting is handled differently in FS1 and FS2. FS1 allows a dif- 
ferent DS condition code to be reported for each destination, but provides 
minimal diagnostic report information. In FS2, a single MU reports only one 
exception, but extensive reporting information may be provided. 


If a bilingual DSU receives an FS1 MU with multiple condition codes, it gen- 
erates multiple FS2 DRMUs, one DRMU for each unique condition code. 
This can be done by sorting the FS1 condition codes, and generating an FS2 
DRMU for each unique code. A single FS1 Dist_MU type REPORT with a DS 
Report may cause a bilingual DSU to generate up to four FS2 DRMUs. For 
more detail of this process, refer to “FS1 Specific DS Reports.” 


4. The DS condition code is mapped to an SNA _report_code. See section 
Appendix E. for the exact mappings. 


5. The origin_seqno field is ignored (and discarded). 
6. The dist_flags are set to specify exception_report (NO). 


7. The presence of a server_object or agent_object in the FS1 MU causes the 
distribution to be terminated. 


8. All reported-on destinations are users. However, the reported-on_dest RGN 
and reported-on_dest_REN are omitted within the reported-on_dest_DSU. 


9. The FS2 distribution is sent with high integrity. 


FS1 Specific DS Reports 
As mentioned earlier, a single FS1 Dist_MU type REPoRT with a DS report may 
contain different condition codes. In practice, multiple exceptions rarely occur 
simultaneously for a single distribution, so typically the report contains only one 
condition code. Nonetheless, to understand how many unique condition codes 
may occur in a single FS1 DS report, divide the condition codes into three 
groups (see Figure 59 on page 394.) The first group contains only Routing 
Exception and Unknown User Name, which are the FS1 exception conditions 
having a scope of “Destinations” as described in Appendix E. If an FS1 DSU 
receives a distribution and checks for these exceptions, some destinations 
might have a Routing Exception, some others might have an Unknown User 
Name, and others may have neither exception condition. 


The second group of condition codes contains Unknown Resource 
Name—Specific Server, Invalid Server Parameters, Unknown Resource 

; Name—Agent TP and Specific Server Exception. The scope of these exceptions 
is “Local-only Destinations.” These exceptions can occur only at the destination 
DSU. Each of these conditions must apply to all of the local destinations or 
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none of the local destinations. For example, if the specific server is unknown 
for one local user, it will be unknown for all local users. 


The third group of condition codes includes all the other exception conditions, 
each having the scope of ’Distribution Copy.” Each of these conditions applies 
either to all destinations or no destinations of an MU. For example, Hop Count 
Exhausted is in this third group. Since the hop count is maintained on a distrib- 
ution copy basis, the Hop Count Exhausted exception will affect all destinations 
in that distribution copy. 


Given any distribution, an FS1 DSU may detect either or both codes from group 
1, but at most one from group 2 and at most one from group 3. Thus, the FS1 
DSU may report up to four condition codes for any given MU. 


Codes that might apply to some destinations and not others: 
Routing exception 
Unknown user name 


Codes that apply only at destination DSUs, and apply to all destinations or no destinations: 
Unknown resource name—specific server 
Invalid server parameters 
Unknown resource name—agent TP 
Specific server exception 


Codes that must apply to all destinations or no destinations: 
Hop count exhausted 
Format exception 
Function not supported 
Operator intervention—purged 
User names lost 
Resource not available 
System exception 
Insufficient resource 
Storage-medium exception 
REMU exception 
server object size incompatible with capacity level 


Figure 59. Groupings of DS FS1 Condition Codes 


For example, suppose that a DSU with a DSU name of D1 receives a Dist_MU 
type TRANSPORT. Also, assume that the DSU names D2, D3, and D4 appear in the 
intervention list at D1. Further, suppose that the DMU’s received hop count 
value was 1, that a format exception was detected during receipt, and that 
neither the agent nor the server specified in the DMU exists at this DSU. The 
destination list (and the errors associated with each destination) is given below: 


e User=u1, DSU= 01. The directory indicates that u1 is an unknown user 
name. 


e User=u2, DSU=b2. The directory indicates that U2 is an unknown user 
name. 


e User=u3, DSU=p3. This is a valid local user. 
e User=u4, DSU=p4. This is a valid local user. 
e User=u5, DSU=pD5. The routing table indicates that D5 is a routing error. 
e User=u6s, DSU=p6. The routing table indicates that Dé is a routing error. 


e User=u7, DSU=o07. The directory indicates that U7 is an unknown user 
name. The routing table indicates that D7 is a routing error. 
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e User=us, DSU=ps. The directory indicates that U8 is an unknown user 
name. The routing table indicates that D8 is a routing error. 


e User=u9, DSU=Dos. This is a valid remote user. 


This DSU happens to check for exceptions in the order given in Figure 59 on 
page 394. Routing exceptions are checked first, and destinations U5, U6, U7 and 
Us are flagged. Unknown user names are checked next, and U1 and u2 are 
flagged. Users u7 and us would have been flagged for unknown user names, 
but they were previously flagged as being routing exceptions. The check for 
Unknown Resource Name—Specific Server causes the remaining local users to 
be flagged, u3 and u4. Unknown Resource Name—Agent TP will not be 
reported, since all of the valid local users (U3 and U4) have already been 
flagged as having Unknown Resource Name—Specific Server. Since the 
received hop count is 1, the distribution cannot be forwarded because a Hop 
Count Exhausted condition exists. All of the remaining remote users (only ug in 
this example) will thus be flagged with Hop Count Exhausted. Format Exception 
will not be reported because no valid destinations remain. Thus, in spite of the 
fact that six exception conditions exist, only four (Routing Exception, Unknown 
User Name, Unknown Resource name—Specific Server and Hop Count 
Exhausted) will be reported. 


DIA Report Mapping 


This section discusses in detail the Format-Set-1/Format-Set-2 mappings for DIA 
reports. This mapping is unusual in that an FS1 report flow is mapped to (or 
from) an FS2 transport flow. Figure 60 shows the atomic structures not directly 
related to the DIA report, and Figure 61 on page 397 shows how FS2 DTMUs 
contain an FS1-style DIA report in a mixed network. 


A DSU supporting an open protocol boundary makes the DIASTATUS and DIA 
agent names available to the local DIA application program. This application 
program should send DIA report information using a Send_Distribution verb 
with origin_agent set to DIA, dest_agent set to DIASTATUS and Server set to DIA. 


FS2 DTMU to FS1 DIA Report Structure Mappings 


FS2 Structure FS1 Structure 


HOP_COUNT HOP_COUNT 
DIST FLAGS 
SERVICE_PARHS 
DEST_AGENT 
SERVER 


ORIGIN RGN 


Figure 60. FS2 DTMU to FS1 Dist_MU type Report (DIA Report) Mapping 
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Notes on execution-time checks and actions, FS2-to-FS1: 


14. Unless otherwise noted, the FS2 structure values are simply copied to their 
FS1 counterparts. 


2. The fields of the FS1 Dist_MU type REPoRT that are not specifically devoted 
to agents or report information (e.g., origin_RGN and origin_REN of the FS1 
Dist_MU type REPORT), are mapped from FS2 DTMU’s prefix, command, and 
destination _list portions according to the rules given above for transport MU 
mapping (see section “Transport Mapping” on page 389). 


3. If the DTIMU’s priority service parameter is less than CONTROL, the FS1 MU’s 
priority is set to CONTROL. FS1 protection is set to YES, capacity is set to 
ZERO. 


4. The contiguous section of the FS1 Dist_MU type REPORT consisting of the 
dist_report_operands (see Figure 57 on page 389) is copied from the FS2 
MU’s server_object. 


The byte stream to be copied to the FS1 Dist_MU type REPORT begins 
with the first LLID inside the server_object, which must be ID=C340 or 
ID=C361. (Otherwise, the translation is terminated.) 


Subsequent LLIDs of the server_object are also copied into the FS1 
Dist_MU type REPORT without modification, until the termination condi- 
tion is detected. 


The termination condition is two consecutive LLIDs with LL=5, 
ID=C351. The two terminating LLIDs are included in the FS1 Dist_MU 
type REPORT. 


Exhaustion of the server_object without detecting the termination condi- 
tion causes the translation (and distribution) to be terminated. 


Any data left in the server_ovject is discarded. 


5. The FS1 dest_agent is set to DIA. The distribution_type bit is set to REPORT. 


6. No FS1 server is specified. 


7. The server_object_byte_count is ignored (if supplied). 


Notes on execution-time checks and actions, FS1-to-FS2: 


1. Unless otherwise noted, the FS1 structure values are simply copied to their 
FS2 counterparts. 


2. The fields of the FS2 DTMU prefix, command, and destination_list that are 
not specifically devoted to agents or report information are mapped to the 
FS1 Dist_MU type REPORT according to the rules given above for transport 
MU mapping (see section “Transport Mapping” on page 389). 


3. If the FS1 priority is CONTROL, then the FS2 priority is set to REQUIRE_LEVEL_GE 
DATA16. FS2 capacity is set to REQUIRE_LEVEL_GE 16MB. 


4. The FS1 Dist_MU structure dist_report_operands (see Figure 61 on 
page 397) is copied to the FS2 MU’s server_object. (This means that the 
first ID of the server_object will be either C340 or C361; the last two IDs of 
the server_object will be identical: LL=5, ID=C351.) 
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5. The FS2 DTMU’s dest_agent is DIASTATUS, the origin_agent is DIA and the 
Server is DIA. The exception_report flag is set to NO. 


6. Bilingual DSUs may calculate the length of the server_object and supply the 
server_object_byte_count. 


7. The F82 distribution is sent with high integrity. 


FS1 DMU (Type Report) with DIA Report 


Format Set 1 DMU (Type Report) 
DIA Report Atomic Structures 


REPORT_CORRELATION 
REPORTED-ON_ORIGIN DGN 
REPORTED-ON_ORIGIN_DEN 
REPORTED-ON_SEQNO 
REPORTED-ON_ORIGIN DTM 
REPORTED-ON_AGENT_CORR 
GEN _DIA_TYPE 
GEN _DIA_ CONTENTS 
BEGIN _REPORT_DGN LIST 
REPORTED-ON_DEST_DGN 
BEGIN REPORT _DEN LIST 
REPORTED-ON_DEST_DEN 
SPEC_DIA_TYPE 
SPEC_DIA_CONTENTS 
END_REPORT DEN_LIST 
END_REPORT_DGN LIST 
(other LLIDs may occur in FS2 flow, and will be truncated) 


Format Set 2 DTMU 
Server Object 


Server 
Object 


FS2 DTMU with DIA-Report Coexistence Indicated by Agent=DIASTATUS 
Figure 61. Coexistence Mapping of FS1 DIA Report to DTMU Server Object 


Null RGN Handling 


One subtle, but significant, difference between FS1 and FS2 involves RGNs. FS‘1 
allows a “null RGN’ to be used, in which no RGN value is given. A null RGN is 
encoded with an LT that has a length of 2 and no atomic data (see Appendix G 
for further details). The FS1 assumption is that, just as a RGN may have a 
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value of, say, A, NET5, OF USCO1NS5, it may also have an empty (or null) string as 
its value. In this last case, the RGN is said to be nu//. FS2 does not allow null 
RGNs, but requires that a non-null RGN value be used in all MUs whenever a 
DSU name is specified. (Usually this RGN value will merely be the appropriate 
network ID.) 


To allow FS1 implementations using null RGNs to coexist with FS2 implementa- 
tions, which consider null RGNs to be illegal, the system administrator should 
define a specific (i.e., non-null) value to the FS2 implementations for the FS‘1 
null RGN. This special RGN value is inserted by a bilingual DSU’s FS‘ 
DS_Receive process whenever a null RGN is received, and transformed into a 
null RGN by the bilingual DSU’s FS1 DS_Send process. 


This is most easily understood by the following example: Let ”<null>” denote 
a null RGN, and suppose the system administrator has chosen NRGNVAL to be 
the FS2 name for the FS1 null RGN. User (DGN=peEpTA, DEN=ALICE) is located 
at an FS1-only DSU named (RGN= <null>, REN=systema). User 
(DGN = bvePTB, DEN=BILL) is located at an FS2-only DSU named (RGN = NETWkB, 
REN=SYSTEMB). The bilingual DSU between the FS1 and FS2 subnets is known 
by two DSU names, (RGN=NETWKC, REN=SyYSsTEMC) and (RGN= <null>, 

REN =SyYSTEMC) This network is shown in Figure 62. 


FS1 Network 


User=DeptA.Alice 
® 
DSU=<nul ]>. SystemA 


DSU=<null>.SystemD 


fee ee ot ag cys, 
DSU=NetwkC. SystemC 


User=DeptB. Bil] 


DSU=NetwkB. SystemB 


FS2 Network 
Figure 62. Null RGN Handling Example—Network, DSUs, and Users 


The following system data structures exist in the various DSUs: 
e At DSU (<null>.sYSTEMA) 


The directory contains 


DeptB.* > <null>.SystemD 
DeptA.Alice + local user queue #5 


The routing table contains 


<null>.SystemD + <null>.SystemD 


At the bilingual DSU (NETWKC.SYSTEMC) 


The directory contains 
DeptB.Bill > NetwkB.SystemB 
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The routing table contains 


NRGNVAL.SystemA > <null>.SystemA 
NetwkB.SystemB + NetwkB.SystemB 


The intervention list contains 
NRGNVAL.SystemD 


The “null RGN value” is defined as NRGNVAL. 
e At DSU (NETWKB.SYSTEMB) 


The directory contains 


DeptB.Bill > local user queue #8 
DeptA.Alice > NRGNVAL.SystemA 


The routing table contains 
NRGNVAL. * + NetwkC. SystemC 


These tables are shown in Figure 63 on page 400. 
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Figure 63. Null RGN Handling Example--Data Structures 


If DEPTA.ALICE sends a distribution to DEPTB.BILL, the Dist_MU sent from the origin 
to the bilingual DSU will contain the following values. 


Origin User: DGN=DeptA DEN=Alice 
Origin DSU: RGN=<null> REN=SystemA 
Dest User: DGN=DeptB DEN=Bill 
Dest DSU: RGN=<null> REN=SystemD 


The distribution will be received by the bilingual DSU, and the null RGN values 
will be replaced with NRGNVAL in the FS1 DS_Receive process. The bilingual 
DSU will then redirect the distribution since the destination DSU 
(NRGNVAL.SYSTEMD) is in the DSU’s intervention list. The directing sublayer will 
determine that the destination user, DEPTB.BILL, is located at NETWKB.SYSTEMB. 
The distribution as forwarded on to NETWKB.SYSTEMB from the bilingual DSU will 
have the following fields: 
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Origin User: DGN=DeptA DEN=Alice 
Origin DSU: RGN=NRGNVAL REN=SystemA 
Dest User: DGN=DeptB DEN=Bill 
Dest DSU: RGN=NetwkB DEN=SystemB 


The distribution will be received at NETWKB.SYSTEMB and delivered to DEPTB.BILL 
as would any other distribution. This example is shown in Figure 64. 


@eeoeeoeeaeovoeoeoeaevneaeveeeeoeeneeoneneensee@ 


¢ Origin: DeptA.Alice 
at <null>.SystemA ° 


FS1 Network 


DeptB.Bil] 
<null>.SystemD - 


@eeaenveeenovoe een eeeeeaaeaneaeeaeaweaanennaee 


° Origin: DeptA.Alice 
at NRGNVAL.SystemA: 


DeptB.Bill 
NetwkB.SystemB ° 


@eeeeveevneeveeaneeeeaneaeeneeene ed 


FS2 Network 


Figure 64. Null RGN Handling Example—Distribution Flow 


Now suppose that DEPTB.BILL sends a distribution to DEPTA.ALICE. The distrib- 
ution as originated from Bill’s DSU will have the following fields: 

Origin User: DGN=DeptB DEN=Bill 

Origin DSU: RGN=NetwkB REN=SystemB 


Dest User: DGN=DeptA DEN=Alice 
Dest DSU: RGN=NRGNVAL REN=SystemA 


At the bilingual DSU, the distribution will not be redirected. The RGN =NRGNVAL 
field will be converted to a null RGN by the bilingual DSU’s FS1 DS_ Send 
process, and the distribution as sent by the bilingual DSU and received by 
DEPTA.ALICE’S DSU will have the following fields: 


Origin User: DGN=DeptB DEN=Bil] 
Origin DSU: RGN=NetwkB REN=SystemB 
Dest User: DGN=DeptA DEN=Alice 
Dest DSU: RGN=<null> REN=SystemA 


Null RGNs in the report_to_RGN field are handled analogously. 


FS1 Atomic Structures Not Present in FS2 


The following Dist_MU type TRANSPORT atomic structures from FS1 are not 
mapped into FS2: 


e server_object_ind 


This structure is unnecessary in FS2. The presence of a server object is 
signalled by the presence of the server object LLID. 
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e server_parms 
This structure was not used by FS1 applications. 
The following FS1 Dist_MU type REPORT atomic structures are not mapped into 
FS2: 
* origin_seqno 


This structure has a constant value in FS1 report flows. It may be assumed 
by bilingual DSUs. 


e agent_correl 


This is not the same structure as reported-on_agent_correl. It was not used 
by FS1 applications, and is unnecessary in FS2 since reports are originated 
by the DSU (and no agent is involved to supply an agent_correl). 


e server_object_ind 
This structure was not used by FS1 applications, and is unnecessary in FS2. 
e gen_SNADS_type 


This structure is necessary in FS1 because DS and DIA reports may flow in 
a single MU. In FS2, only DS reports flow in the DRMU, and this structure is 
unnecessary. 


e spec_DS * (all DS specific report fields) 
FS2 uses only general reports. 
e dist flags 


The appropriate values for these flags are assumed in FS2 without an 
explicit structure. 


FS2 Atomic Structures Not Present in FS1 
The following atomic structures in FS2 are not mapped into FS1. 
e MU_ID 


This structure is not part of the distribution, but is used only for the 
hop-to-hop transfer of the DTMU or DRMU. FS1 uses the LU 6.2 
Confirm/Confirmed verbs to transfer a DMU from one hop to the next. 


e MU_instance_number 
This structure is used in FS2 only in conjunction with the MU_ID, discussed 
above. 
The following DTMU atomic structures in FS2 are not mapped into FS1: 
¢ supplemental_dist_infof 


e supplemental_dist_info2 


The following DRMU atomic structures in FS2 are not mapped into FS1: 


e reported-on_origin_RGN 
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reported-on_origin_REN 
reported-on_ dest_agent 
reported-on_supp_dist_infof 
reported-on_supp_dist_info2 
reported-on_dest_agent 
reported-on_origin_agent 


SNA_condition_report (all atomic structures except SNA_report_ code, 
reported-on_dest_DGN and reported-on_dest_DEN) 
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Appendix E. 


Introduction 


Exception Handling 


This appendix describes protocols for reporting DS-detected conditions. In so 
doing, this appendix includes both references to DS encoding constructs 
described in Appendix G and references to the introduction on exception han- 
dling presented in Chapter 1. 


DS exception conditions can be detected at any of the four DS sublayers, and 
the exception can be reported in a variety of ways depending upon the detector 
and characteristics of the condition. This appendix identifies reportable condi- 
tions and describes the reporting and exception actions. For implementations 
where FS1 and FS2 functions coexist, exception-code translation tables are pro- 
vided to translate the FS1 condition codes to the FS2 report codes. The 
remainder of this appendix presents a summary of exception conditions that are 
detected by the routing, directing, and transport sublayers. Exception condi- 
tions detected by the presentation services sublayer are described in detail in 
Appendix F and are not specifically addressed in this appendix. 


Types of Reporting Actions 


Given a reportable condition, the reporting action DS takes in response to the 
condition depends upon the detector and the characteristics of the condition. 
Listed below are the types of reporting actions DS may perform. 


Local-Agent Reporting 


Local reporting refers to reports that are delivered, either synchronously or 
asynchronously, only to the local agent (i.e., the agent local to the reporting 
DSU). Local reporting is used to report exception conditions that occur before 
DS has accepted responsibility for a distribution or when DS is performing an 
application-specific operation (i.e., a specific server operation at the origin or 
destination). The report is delivered to the agent across the agent protocol 
boundary. 


MU-Level Reporting 


DS informs the adjacent DSU whenever a condition is detected while in conver- 
sation with that DSU. MU-level reporting is performed when an exception is 
detected at the transport sublayer, and the condition is reported to the partner 
DSU by a SEMU (if DS_Send detects the exception) or by a REMU (if 
DS_Receive detects the exception). The specific protocols are defined in 
Chapter 2 and Chapter 3. 


Distribution Reporting 


Distribution reporting refers to the feedback on the condition of a distribution 
and is requested as part of the original distribution request. If the originator 
requests reporting on the condition of a distribution, DS will generate and send 
a distribution report to the report-to DSU/user whenever the responsible DSU 
has detected or has been informed of a condition that interferes with successful 
delivery of the distribution. The SNA_condition_report (SNACR) is provided as 
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part of the distribution report and contains specific information about the excep- 
tion. Since distribution reporting is requested as part of the distribution 
request, distribution reporting is appropriate only for DTMUs and DCMUs and is 
not performed for failed DRMUs or for any control MUs. 


Note: If the report-to DSU/user is local to the reporting DSU, the distribution 
report is passed across the protocol boundary on the 
Receive_Distribution_Report verb. In the non-local case, the distribution report 
will flow through the network as a DRMU. 


Local-Operator Reporting 
Whenever an exception condition has triggered a distribution report or a local- 
operator report, the DSU logs the exception condition in the exception log and 
informs the local operator, if an operator is available at that DSU. 


When the DSU is capable of rerouting distributions, the operator may be noti- 
fied without creating a distribution report. In these cases, the operator is given 
an opportunity to reroute distributions that would fail in a less capable DSU. 
The following conditions fall into this category: 


e Routing exception 

e Function not supported 

e System exception (condition is at adjacent node) 
e MU sequence exception 

e Repeated conversation problems 


Note: The rerouting function gives the operator the ability to retry conditions 
that are not usually considered retriable (i.e., routing exception). 


Exception Logging: When the DSU detects an exception condition, it creates an 
entry in the exception log that describes the condition encountered. The fol- 
lowing information is logged for every condition. 


¢ Name of the transaction program that detected the exception 
¢« Date 

e Time 

e SNA_report code 

e Additional exception information 


Depending upon the exception, the following additional information is logged 
whenever appropriate. 


e distribution_ID 

e MU_ID 

e reported-on_destinations 

e Session information 

e LU 6.2 information 

¢ SEMU 

e REMU 

e Implementation-specific information 
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Characteristics of Exception Conditions 


Retriable Conditions 


Reportable conditions are either retriable or non-retriable. Retriable conditions 
are not message-unit-specific. The same message unit might have been suc- 
cessfully processed had it arrived a moment earlier or later; therefore it is 
expected that the message unit can still be successfully processed when it is 
retried a moment later. Given their characteristic transience, it is not appro- 
priate for these retriable conditions to immediately trigger a local report, dis- 
tribution report, or operator notification. 


If a retriable condition is detected by either DS_Send or DS_Receive, MU-level 
reporting is used to inform the partner about the condition encountered. Then 
the distribution may be retried again later. If DS Receive detects the exception 
and determines that it is retriable, DS_Send may or may not choose to honor 
the receiver's recommended retry action. Only when the retry count has been 
exhausted does the responsible DSU generate a distribution report. 


If the exception detected by DS_Receive is a temporary condition at the 
receiving DSU (i.e., temporary storage medium exception), DS_Send places a 
hold on the next-DSU queues for that connection. When the temporary condi- 
tion has been resolved, an instance of DS_Receive at the receiving DSU is 
expected to allocate a conversation to DS_Send at the sending DSU. The 
attached instance of DS_Send releases the exception-hold and begins sending 
traffic again. 


Non-Retriable Condition 


Condition Scope 


Non-retriable conditions are message-unit-specific. The nature of the condition 
is such that the distribution cannot proceed without a change to the message 
unit. These conditions result in a distribution report, an operator notification, or 
a local report. 


For a non-retriable condition detected by either DS_Send or DS_Receive, 
MU-level reporting is used to inform the partner of the exception and a distrib- 
ution report is generated to inform the report-to DSU/user. For those conditions 
detected outside the transport sublayer, distribution reporting is performed (if 
requested). However, for conditions that are outside the responsibility of DS 
(i.e., specific server exceptions), distribution reporting is not appropriate 
(although the exception may be reported to the local agent). 


For each reportable condition, some portion of the distribution is affected. For 
each reportable condition and for all subcodes of the condition, the portion of 
the distribution affected and the TPs that may detect the exception are identified 
in Table 1. 
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Table 1. Portion of the Distribution Affected by a Reportable Condition and the Detecting TP 
What’s Affected Detecting TP 


om [ale [SE [ mm [oe [ more 
nection | Copy Dests 

Insufficient Resource X X X X X 
Specific Server Exception xX X X X X 
Unknown Resource Name xX X X X X 
System Exception X X X X X X 
Unable to Register MU_ID X X X X 
Operator Intervention X X X X X 
Storage Medium Exception X X X X X 
Server Object Not Found X X X X X 
| Function Not Supported X X xX 

DS Conversation Exception X X X 
Unknown User Name X X X X 
Format Exception X X X X 
Unrecognized Message Unit X X 
Directing Exception X xX X X 
improper DS Usage of LU 6.2 X X X 

MU Sequence Exception X X X 

Invalid Restart Byte-Position X 

Routing Exception X X X 
Hop Count Exhausted X X X 


SNACR Usage, DS Report Codes, and Reports 


DS Usage of SNACR 


The SNA_condition_report is a means by which exception information for any 
type of SNA condition can be reported. The SNACR contains an SNA-registered 
report code and a defined structure identification; therefore, the reason for the 
exception and the location at which the exception was detected can be fully 
described. 


The following list identifies which of the highest-level structures within the 
SNA_condition_report are used by DS: 
¢ SNA_report_code 
Is a 4-byte SNA-registered code that identifies the detected condition. 
e structure_report 


Identifies the header and (conditionally) the contents of DS encoding con- 
structs that are relevant to the specified SNA_report_code. 


e reported-on_dest_list 
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Identifies the list of destinations affected by the SNA_report_code. This 
structure is required by DS in any SNA_condition_report that appears in a 
DRMU. This structure is precluded in the REMU. 


e supplemental _report 


Contains the additional exception data that is relevant to the report code. 


Further detail regarding DS’s use of the SNA _condition_report is described in 
the sections that follow. 


SNA-Registered DS Conditions 
The following table provides a condensed description for each SNA-registered 
DS condition. The table identifies, for each DS condition, the corresponding 
SNA-registered report code, the contents of the SNACR report structures, and 
the recommended retry action. A formal description of the SNA-registered 
report codes and contents of the report structures can be found in the “Sense 
Data” chapter of the SNA Formats manual. Unless otherwise stated, the sug- 
gested retry actions for sender-detected conditions are identical to the receiv- 
er’s recommended actions. 


Table 2 (Page 1 of 5). SNA-Registered Report Codes for DS and SNACR Contents 


SNA Report Code Structure Report 


Number 
Insufficient Resource 


Contents 
Insufficient resource | _o8i2 | 001 | 0 | WA | WA | Expected 


Specific-Server Exception 


Specific-server exception 085A 0000 Foo | NA TNA Precluded 


Unknown Resource Name 


Server Name 
Agent 


System Exception 


Toor [of wa | WA | xpected 


MU_ID 
N/A Registry Precluded 
Values 


Suggested 
Retry Action 


Supplemental 
Report 


MU_ID 
N/A Registry Expected 
Values 
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Table 2 (Page 2 of 5). SNA-Registered Report Codes for DS and SNACR Contents - 


SNA Report Code |. Structure Report 


Structure 
Contents 


Supplemental 
Report 


Suggested 
Retry Action 


Subcode 


MU_ID not accepted due to a 


permanent registry condition 085D 


MU_ID registry is not initial- 


ized 085D 


Operator Intervention 


Suspending 
Purging 


N/A 


Expected 
ie (See Note 6) 
Storage-Medium Exception 


exception 
exception | 


Server Object Not Found 


Function Not Supported : | 
Service 
triplet(s) 


Service parameter not sup- 


ported hs 


= 
— 
> 
“0 
— 
fi 

& 
c 

2. 
@ 

Q. 


Service parameter level not 


supported ove 


| Destination-role function not 
supported 
(See Note 3) 


0018 


All-role function not sup- 
ported 
(See Note 3) 


1003 


Reserved 001A N/A 


Unable to initiate agent (See 
Note 4) 


Function conflicts with FS1 
encodings 


001B 


001C Data value 


ae 


N/A N/A Precluded 


N/A 


Reserved 001D N/A 


= 
> 


Reserved 


Multiple-destination traffic not 


supported oe 


1003 


DS Conversation Exception 


Unable to allocate a conver- 


1008 
sation 


6046 


{Detected a RESOURCE FAILURE 1008 6047 


Detected a Deallocate 


Type(ABEND) return code ~ 


—- 6048 
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Table 2 (Page 3 of 5). SNA-Registered Report Codes for DS and SNACR Contents 


SNA Report Code Structure Report 
Code Subcode 
Contents 


Unknown User Name 


Format Exception 


Required structure absent 100B | oot | ot) | NA LNA Precluded 
Precluded structure present 100B 0002 N/A Precluded 


Multiple occurrences of a Data value of 
non-repeatable structure 2nd occur- N/A Precluded 
rence 


Supplemental 
Report 


Suggested 
Retry Action 


100B 0003 


a 


Data value of 
max+ 1 occur- 


Excessive occurrences of a 
repeatable structure 


Unrecognized structure 

100B 
present where precluded 
Length outside specified 100B 
range 


100B 0004 Max value Preciluded 


rence 


1 (See 
Note 1) . 


0005 Precluded 


0006 Preciluded 


A 

Length exception 100B 0007 Precluded 

peguired:- commnaticn of 100B 0008 >1 N/A N/A Precluded 

structures absent 

Precluded combination of 100B 0009 4 Precluded 

structures present | 

Required combination of 

structures and data values 100B 000A >1 Data value N/A Precluded 

absent | 

Precluded combination of 

structures and data values 100B 000B >1 Data value N/A Precluded 

present | 

Incompatible data values 100B | 000D Precluded 
| Precluded character present 1008 | 000 : ae parmaiis Brecladed 

Data value out of range 100B OOOF | 1 | Data value | Max in range | Precluded 

Segmentation occurred when 100B N/A N/A Praciuaca 

precluded 

structure 

| None of several possible 100B 1 (See Data value NVA Beadladed 

structures found Note 1) | possible 

Incorrect order of child struc- | Header of the 

tures found 100B ; 0014 parent struc- N/A Precluded 

| ture 
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Table 2 (Page 4 of 5). SNA-Registered Report Codes for DS and SNACR Contents 


SNA Report Code Structure Report 
Condition Number 
Code Subcode Structure 
Contents 


Unrecognized Message Unit 


Unrecognized message unit 100C 0001 rae Precluded 


Directing Exception (See Note 4) 

Agent name known but not 0001 N/A Precluded 
supported for user destination 

Agent name known but not 

supported for DSU destina- 100E 0002 N/A Precluded 
tion 


Agent name known but is not | 


Improper DS Usage of LU 6.2 


Improper DS usage of LU 6.2 100F 0001 | oo 6] UNA NAY Precluded 


MU Sequence Exception 


MU_ID already terminated 1018 
MU_ID state mismatch 1018 


Reserved 


Terminate conversation 
ignored 


N/A 
N/A 
N/A 
RRMU not followed by a | 
N/A 
CHANGE_DIRECTION Indicator 
RBP > 1 plus 


Precluded 
last_byte_received value. 1018 | 0001 oe 
not supported. 
Unable to restart at indicated 1019 RBP Values Precluded 


RBP 


Routing Exception | 


Precluded } 


Pe eri renicamanre', 8019 0002 ¥ 4 NA | NAM Precluded 


No connection for specified 8019 0004 Service N/A Precluded 
service level triplets 
Hop Count Exhausted 


Conditions for Specific FS1 Exceptions : 


Supplemental | 
Report 


Suggested 
Retry Action 


Expected 


Precluded 


Precluded 


Precluded 


= 
> 
< 
> 
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Table 2 (Page 5 of 5). SNA-Registered Report Codes for DS and SNACR Contents 


SNA Report Code Structure Report 
Number 
Code Subcode Structure 
Contents 


Resource not available O84F 0000 


Suggested 
Retry Action 


Supplemental 


REMU exception 1012 0000 
Invalid server parameters | 1013 0000 


Notes: 


Server object size incompat- N/A N/A Precluded | 
ible with capacity level 


. For these conditions, the sibling list may be included within the SNACR. 


2. For these conditions, the structure_byte_offset and structure_segment_number may be included within the 
SNACR. 


. For these conditions, the structure_byte_offset is present whenever the corresponding structure_contents 
does not represent the beginning of the structure. The structure_segment_number is present if the 
reported-on structure is not contained in the first segment. 


4. For these conditions, a supp/ementa!_report is not present, because the DRMU contains the appropriate 
report fields. 


5. For these conditions, the supplementa/_report is present whenever the structure_report does not identify the 
unsupported functions. 


6. If the partially received distribution is purged by an operator at the receiving DSU, retry is expected. 
However, if the operator purges the distribution copy from the sender’s queue, retry is precluded. 


Generating a Distribution Report 
Whenever a condition is detected for which a distribution report is generated, 
certain information specified in the distribution request is used to create the 
distribution report. Listed below is an explanation of how a distribution report 
is constructed. 


¢« The hop count is set for the report. 


e The service_parms in the DRMU are set to the specified 
report_service_parms in the DTMU. If they are absent, the service_parms 
are derived by the reporting DSU from the values specified in the DTMU. 


e The report-to_agent is set to the report-to_agent value in the DTMU. If the 
report-to_agent is absent in the DTMU, it defaults to the origin agent value. 


¢ The reporting DSU is set to the name of the DSU generating the report. 
e The report_DTM is set to the date and time the report was generated. 


e The report-to_DSU_user is set to the specified report-to_DSU and report- 
to_user values in the DTMU. If these fields are absent, it is set to the 
origin DSU and origin_user values in the DTMU. 


¢ If the report is to be sent to a DSU other than the origin _DSU specified in 
the DTMU, the reported-on_origin_DSU field is generated and is set to the 
origin_DSU value of the DTMU. 
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e If the report is to be sent to a user other than the origin_user specified in 
the DTMU, the reported-on_origin_user field is generated and is set to the 
origin_user value of the DTMU. 


¢ The reported-on_seqno_DTM is set to the seqno_DTM value in the DTMU. 


e The reported-on_supp_dist_infot field is set to the supplemental_dist_infot 
value in the DTMU. : 


¢ The reported-on_agent_correl is set to the agent_correl value in the DTMU. 


e The reported-on_origin_agent is set to the value of the origin_agent if the 
report-to_agent value in the DRMU is different from the origin_agent value 
in the DTMU. 


¢ The reported-on_dest_agent is set to the value of the dest_agent if 
dest_agent is specified in the DTMU. 


¢ The receiving DSU is set to the name of the DSU that detected the excep- 
tion if different from the reporting DSU name. 


e The SNA_condition_report is constructed according to the type of condition 
detected. | 


e The reported-on_supp_dist_info2 is set to the value of 
supplemental_dist_info2 if it is present in the DTMU. 


Bilingual Node: Mapping SNA Report Codes and FS1 Condition 
Codes 


The following tables describe the translation of exception codes between 
Format Set 1 and Format Set 2. In FS1, the DS condition codes were described 
by a 2 byte, DS-unique code. The DS condition codes were very general and 
did not provide a detailed method of reporting exception conditions. In FS2, the 
exception conditions are described by a 4-byte, SNA-unique code, which con- 
sists of a primary code and subcode. By using SNA-registered report codes, 
exception conditions can be categorized and a more precise description of the 
condition can be reported. . | 


Table 3 (Page 1 of 2). FS2 SNA Report Code to FS1 Condition Code Mappings 


SNA Report Code FS1 Condition 


Insufficient Resource 


User Names Lost 
Resource Not Available 
Specific-Server Exception 
Unknown Resource Name 
Server 
Agent 


System Exception | 
All subcodes 
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Table 3 (Page 2 of 2). FS2 SNA Report Code to FS1 Condition Code Mappings 


SNA Report Code FS1 Condition 


Unable to Register MU_ID 
All subcodes 


Operator Intervention 
All subcodes 
Storage-Medium Exception 
All subcodes 
Server Object Not Found 
All subcodes 
Function Not Supported 
All subcodes 
DS Conversation Exception 
Allocation exception 
Resource Failure 
Deallocate Type(ABEND) 
Unknown User Name 
Format Exception 
All subcodes 
Unrecognized Message Unit 


Server-Object Size Incompatible with 
Capacity Level 


Directing Exception 

All subcodes | 
Improper DS Usage of LU 6.2 PS 
REMU Exception 
Invalid Server Parameters 
MU Sequence Exception 

All Subcodes 


Invalid Restart Byte-Position 
All Subcodes | 
Routing Exception 


All subcodes 
Hop Count Exhausted 
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Table 4. FS1 Condition Code to FS2 SNA Report Code Mappings 


FS1 Condition SNA Report Code 


Routing Exception 
Unknown User Name 
Hop Count Exhausted 


Format Exception 


Function Not Supported 


Specific-Server Exception 


Unknown Resource Name 


Server 


Agent 
Invalid Server Parameters 


Operator Intervention 


Purging 


User Names Lost 


Resource Not Available 


System Exception 
insufficient Resource 


Storage-Medium Exception 
REMU Exception 


Server-Object Size Incompatible with 
| Capacity Level 


Note: If the condition was receiver-detected and the receiver provided 
exception_and_reply_data in the FS1 REMU, the exception_and_rep/y_data is encoded 
within the supp/emental_report of the SNA_condition_report for FS2 reporting. If the 
condition was sender-detected or detected outside of a conversation context and the 
detecting component routinely generates exception_and_reply_data to log, the logged 
exception_and_reply_data is also encoded within the supp/ementa/_report of the 
SNA_condition_report for FS2 reporting. 


Exception Handling and Analysis 


The tables that follow provide a summary of exception conditions that can be 
detected by DS_Send, DS _ Receive, and DS_Router_Director. The conditions 
are presented in a logical processing order in which the exceptions could be 
detected. The analysis tables describe exception handling only for those dis- 
tributions for which high integrity was specified. No examples of basic-integrity 
traffic are shown. In the analysis tables, each exception condition is associated 
with each of the following: 


e The portion of the distribution affected by the condition. The exception may 
affect the entire distribution copy, all destinations, or local destinations; 
however, the condition may affect not only the distribution but also the con- 
nection between DSUs or an entire DSU. 


e The appropriate retry and reporting responsibilities. This describes 
whether the condition is retriable or non-retriable and indicates the corre- 
sponding reporting actions. 
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e The registered SNA_report_code that identifies the condition. 


e The exception handling actions to perform in order to recover from the 
exception. 


Note: For a more detailed discussion about exception handling performed by 
DS_Send and DS _ Receive refer to “Exceptions Detected by the Distribution 
Transport Sublayer” on page 89. For a discussion of server-related exceptions 
see “Servers and Objects” on page 40. : 


Exception Conditions Detected During the Sending Process 


Table 5 (Page 1 of 5). Exception Processing When Conditions Are Detected by DS Send 
SNA 
. What’s Retry / Reporting Other Exception 
Exception Conditions Affected Acigne Report ‘Aetione 
Code 
Exception conditions detected by LU 6.2 when DS_Send attempts to allocate a conversation with DS_ Receive. 


Connection | Retry is allowed. Log {1008-6046 | Attempt to re-allocate 
the exception. the conversation. 


Connection | Retry is precluded. Log| 1008-6046 | Await operator action. 
the exception and 
inform the operator. 


Exception conditions detected by LU 6.2 while DS_Send is in conversation with DS_Receive. 


DS_Send detects from LU 6.2 a Connection | Retry is allowed. Log {1008-6047 |Attempt to re-allocate 
the exception, inform the conversation. 
the operator, and send 
a SEMU to the partner. 
When retry is 
exhausted, log the 
exception, inform the 
operator, and send a 
SEMU to the partner. 


return code of RESOURCE_FAILURE. 
1008-6047 | Hold the queues and 
Retry is allowed. Log 


await operator action. 
1008-6048 
the exception, inform 


the operator, and send 
1008-6048 
Exception conditions detected by the DSU’s queue service when reading an entry from the next-DSU queue. 


a SEMU to the partner. 
100F-0001 
DSU 0879-0001 
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LU 6.2 was unable to allocate a con- 
versation with DS Receive because 
no sessions were available. 


LU 6.2 was unable to allocate a con- 
versation with DS_Receive, because 
the parameters were incorrect, the 

TP was unknown, or a remote or 
local LU exception has occurred. 


DS_Send detects from LU 6.2 a 
return code of Deallocate 
Type(ABEND). 


Attempt to re-allocate 
the conversation. 


Hold the queues and 
await operator action. 


When retry is 
exhausted, log the 

exception, inform the 
operator, and send a 
SEMU to the partner. 


Retry is precluded. Log 
the exception and 
inform the operator. 


Issue Deallocate 
Type(ABEND). 


DS_Send has detected that the 
receiving DSU has issued an 
improper sequence of LU 6.2 verbs. 


Attempt to perform the 
I/O operation again. 


Retry is allowed. Log 
the exception and 
inform the operator. 


The storage medium detected a 
temporary failure. 


Table 5 (Page 2 of 5). Exception Processing When Conditions Are Detected by DS_Send | 


What’s Retry / Reporting a - Other Exception 
Affected Actions P Actions 
Code 
Retry is precluded. Log | 0879-0002 | Hold the next-DSU | 
queues and await oper- 
ator action. 
the connection. Log 


the exception and 
inform the operator. 
085E-0001 | Hold the next-DSU 
queue and await oper- 
ator action. 
the exception. 
Retry is allowed. Log {085C-0001 | Attempt to read the 
the exception and 
inform the operator. 
When retry is 085C-0001 
exhausted, log the 
exception, and inform 
the operator. 


queue entry again. 
Exception conditions detected by the DSU when DS_Send attempts to process control MUs. 


-_ 


_ 


_ 


Exception conditions detected by the DSU when attempting to begin the MU transfer to the partner. 
occurred when attempting to assign 


Connection | Retry is precluded. Log |085D-0004 | Hold the next_DSU 
the exception and queues and issue Deal- 
an MU_ID to the DMU. inform the operator. locate Type(ABEND). 


Hop count ts 0. Dist Copy | Retry is precluded. Log|801C-0001 | Terminate the distrib- 


the exception, inform ution copy. 
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Exception Conditions 


The storage medium detected a per- 
manent failure. 


Retry is allowed when 
the operator releases 


Operator has suspended further 
processing for this connection. 


Queue service encounters an excep- 
tion that prevents further processing 
of this queue. 


Hold the next-DSU 
queues and await oper- 
ator action. 


issue Deallocate 
Type(ABEND). 


Retry is allowed. Log 
the exception. 


An exception was encountered when 
attempting to enqueue the control 
MU on the control MU queue. 


085C-0001 | Hold the queues and 
issue Deallocate 


Type(ABEND). 


Retry is allowed. Log 
the exception and 
inform the operator. 


An exception condition was encount- 
ered when attempting to send a 
control MU. 


085C-0001 | Issue Deallocate 


Type(ABEND). 


Retry is allowed. Log 
the exception. 


An exception occurs that prevents 
further processing of this control 
MU. 


A CRMU was received with an 
MU_ID iN-TRANSIT, SUSPENDED, COM- 
PLETED, Of PURGED state, but the 
MU_ID registry indicates a 
NOT-ASSIGNED state. 


A REMU was received for which the 
MU_ID is in NOT-ASSIGNED state. 


Hold the queues and 
await operator action 


Retry is precluded. Log 
the exception and 
inform the operator. 


Hold the queues and 
await operator action 


Retry is precluded. Log 
the exception and 
inform the operator. 


An MU_ID registry exception 


the operator, send a 
SEMU to the partner, 
and deliver a dist 
report to the specified 
DSU/user. 


Retry / Reporting 
Actions 


Retry is allowed. Log 
the exception, inform 
the operator, and send 
a SEMU to the partner. 


When retry is 
exhausted, log the 
exception, inform the 
operator, send a SEMU 
to the partner, and 
deliver a dist report to 
the specified DSU/user. 


Retry is precluded. Log 


Retry is precluded. Log 
the exception, inform 
the operator, send a 


The storage medium detected a 
temporary failure. The server 
return code was I/O EXCEPTION. 


Attempt to perform the 
I/O operation again. 


Hold the next-DSU 
queues and await oper- 
ator action. 


Table 5 (Page 3 of 5). Exception Processing When Conditions Are Detected by DS_Send 
Local resources temporarily unavail- | Dist Copy 0812-0011 |Attempt mid-MU restart 
able to continue transfer to the when appropriate; oth- 
partner. erwise, retry with new 
MU_ID. 
0812-0011 | Terminate the distrib- 
7 next-DSU queues. 
Operator has purged this distrib- Dist Copy O85E-0002 | Terminate the distrib- 
the exception, send a ution copy. 
SEMU to the partner, 
report to the specified 
DSU/user. 
The DMU cannot be encoded due to | Dist Copy 100B-ssss_ | Terminate the distrib- 
format exceptions. ution copy. 
SEMU to the partner, 
and deliver a dist 
| DSU/user. | 
Builder exception occurs that pre- Dist Copy | Retry is allowed. Log |085C-0001 | Attempt mid-MU restart 
vents further processing of the the exception, inform 
DMU. the operator, and send erwise ,retry with new 
a SEMU to the partner. MU-ID. 
When retry is 085C-0001 
exhausted, log the copy and hold the 
exception, inform the next-DSU queues. 
ae _ | operator, send a SEMU 
| to the partner, and 
deliver a dist report to 
the specified DSU/user. 
DSU Retry is allowed. Log {| 0879-0001 
the exception, inform 
the operator, and send 
a SEMU to the partner. 
The storage medium detected a per- | DSU Retry is precluded. Log | 0879-0002 
manent failure. The server return 
code was |/O EXCEPTION. the operator, send a 
SEMU to the partner, 
report to the specified 


E tion Conditions What’s Bins “4 Other Exception 
ener re Affected P Actions 
Code 
ution copy and hold the 
ution copy. (See Note 1) 
and deliver a dist 
Exception conditions detected by the builder when attempting to encode the DMU. 
report to the specified 
when appropriate; oth- 
Terminate distribution 
Exception conditions detected by the general server when attempting to read the server object. 
the exception, inform 
and deliver a dist 
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DSU/user. 


Table 5 (Page 4 of 5). Exception Processing When Conditions Are Detected by DS_Send 


SNA 
What’s Retry / Reporting Other Exception 
Exception Conditions Acton Actions 
Code 
Insufficient local resources available | Dist Copy [Retry is allowed. Log /|0812-0011 | Attempt mid-MU restart 
to process the object. The server the exception, inform | when appropriate; oth- 
return code was TEMPORARY SERVER the operator, and send erwise retry with new 
EXCEPTION. a SEMU to the partner. MU-ID. 
When retry is 0812-0011 | Terminate the distrib- 
exhausted, log the ution copy. 
exception, inform the 
operator, send a SEMU 
to the partner, and 
deliver a dist report to 


the specified DSU/user. 


Dist Copy | Retry is precluded. Log|08A6-0001 | Terminate the distrib- 
the exception, inform ution copy. 
the operator, send 
SEMU to the partner, 
and deliver a dist 
report to the specified 
DSU/user. 


Exception conditions detected only by the specific server when DS is attempting to read the server object. 


(Direct Fetch) 
Dist Copy 085B-0001 


The specific-server name specified 
Dist Copy 085A-0000 | Terminate the distrib- 


in the distribution is unknown. 
Exception conditions detected by the DSU when decoding control MUs from DS_ Receive. 


The Parser is unable to decode the | Connection | Log the exception. 100B-ssss 
control MU from DS_Receive. 


or 
100C-0001 
The control MU received contained | Not Appli- | No retry or reporting 
an instance number that is below actions. 


No Code 
the current instance number for the 


The server object specified in the 
distribution request cannot be found. 
The server return code was OBJECT 

NOT FOUND. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a SEMU to the partner. 


Terminate the distrib- 
ution. 


Retry is precluded. Log 
the exception, inform 
the operator, send a 
SEMU to the partner, 
and deliver a server 
report to the local 
agent. 


The specific server has detected an 
exception that prevents further 
processing of the distribution copy. 
The server return code was 
SPECIFIC-SERVER EXCEPTION. 


Issue Deallocate 
Type(ABEND). 


Discard the control MU. 


MU_ID. 


Exception conditions detected by the DSU’s queue service when deleting an entry from the next-DSU queue 
following successful transmission of the DMU. 


Log the exception and |0879-ssss | Await operator action. 
inform the operator. 


The storage device detected a 

failure. 

Retry is suspended. 085E-0001 | Hold the connection 
and await operator 
action. 


Operator has suspended further 
processing for this connection. 


Log the exception. 
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Table 5 (Page 5 of 5). Exception Processing When Conditions Are Detected by DS_Send 


Retry / Reporting Soe 
Affected Actions 
Code 
The queue service encounters an DSU Log the exception and |085C-0001 
exception that prevents further inform the operator. 
processing of the distribution copy. 


Notes: 
1. Because the operator has purged the distribution copy from the sender’s queue, retry is precluded. 


Exception Conditions Detected During the Receiving Process 


Other Exception 
Actions 


Exception Conditions 


Await operator action. 


Table 6 (Page 1 of 6). Exception Processing When Conditions Are Detected by DS_RECEIVE. 
SNA 
: What’s Receiver’s Retry Other Exception 
pacoptten:Conanens Affected Recommendations pail Actions 


Exception conditions detected by LU 6.2 when DS_Receive attempts to allocate a conversation with DS_Send. 


LU 6.2 was unable to allocate a con- | Connection | Retry is allowed. Log | 1008-6046 | Attempt to re-allocate 
versation with DS_Send because no the exception and the conversation. 
sessions were available. inform the operator. | 


LU 6.2 was unable to allocate a con- | Connection | Retry is precluded. Log| 1008-6046 {Stop DS_Receive and 
the exception and await operator action. 
inform the operator. 


versation with DS_Send, because 
Exception conditions detected by LU 6.2 while DS_Receive is in conversation with DS_Send. 


the parameters were incorrect, the 
DS _ Receive detects from LU 6.2 a 


TP was unknown, or a remote or 
Connection | Retry is allowed. Log | 1008-6047 | Attempt to re-allocate 
|return code of RESOURCE_FAILURE. the exception, inform the conversation. 
the operator, and send 
a REMU to the partner. 
When retry is 1008-6047 | Await retry. 
| exhausted, log the 
exception, inform the 
operator, and send a 
REMU to the partner. 


local LU exception has occurred. 

| Connection | Retry is allowed. Log [1008-6048 | Attempt to re-allocate 
the exception, inform the conversation. 
the operator, and send 
a REMU to the partner. 


DS Receive detects from LU 6.2 a 
return code of Deallocate 
Type(ABEND). 


When retry is 1008-6048 | Await retry. 
exhausted, log the 

exception, inform the 
operator, and send a 


REMU to the partner. 


|DS_ Receive has detected that the 100F-0001 | Issue Deallocate 
sending DSU has issued an 


improper sequence of LU 6.2 verbs. 


Retry is precluded. Log | 
the exception and 
inform the operator. 


Type(ABEND). 


Connection 
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Table 6 (Page 2 of 6). Exception Processing When Conditions Are Detected by DS_RECEIVE. 


SNA 
sie What’s Receiver’s Retry Other Exception 
Exception Conditions Affected Recommendations pea Actions 


Exception conditions detected by DS_RECEIVE while receiving DMUs. 
A DMU was received but the MU_ID | Dist Copy 1018-0001 {Discard the MU and 
continue as normal. 
1018-0002 | Discard the MU, send 
all waiting control MUs, 
and deallocate the con- 
versation. 


has already been terminated. 
Dist Copy 
1018-0002 | Discard the MU. 


Dist Copy - 

Dist Copy 1018-0002 | Discard the MU, send 
all waiting control MUs, 
and deallocate the con- 
versation. 

1018-0002 | Discard the MU. 


Dist Copy 
Dist Copy 1018-0004 | Discard the MU, send 
all waiting control MUs, 
and deallocate the con- 
versation. 


Exception Conditions detected by the parser when attempting to decode the DMU. 


Dist Copy 100C-0001 | Discard the MU, send 
all waiting control MUs 
and deallocate the con- 
versation. 

Dist Copy 100B-ssss_ | Discard the MU. 
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Retry is allowed. Log 
the exception, inform 
the operator, and issue 
the Send_Error verb. 

Optionally a REMU may 
be sent to the partner. 


A DTMU was received with an 
MU_ID in the SUSPENDED state. 


Retry is precluded. Log 
the exception, inform 
the operator, and issue 
the Send_Error verb. 
Optionally a REMU may 
be sent to the partner. 


A DTMU was received with an 
MU_ID in the COMPLETED or PURGED 
state. 


Retry is precluded. Log 
the exception and 
inform the operator. 
Optionally a Send_Error 
verb may be issued. 


A DCMU was received with an 
MU_ID in the NOT-RECEIVED state. 


Retry is precluded. Log 
the exception, inform 
the operator, and issue 
the Send_Error verb. 
Optionally a REMU may 
be sent to the partner. 


A DCMU was received with an 
MU_ID in the COMPLETED or PURGED 
state. 


Retry is precluded. Log 
the exception and 
inform the operator. 
Optionally a Send_Error 
verb may be issued. 


DS_Receive has detected that the 
sending DSU has ignored a previous 
terminate-conversation indication. 


Retry is precluded. Log 
the exception, inform 
the operator, and issue 
the Send_Error verb. 
Optionally a REMU may 
be sent to the partner. 


The MU type ts not recognized. Retry is precluded. Log 
the exception, inform 
the operator, issue the 
Send_Error verb, and 
send a REMU to the 


partner. 


The MU cannot be decoded due to 
format exceptions. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


Table 6 (Page 3 of 6). Exception Processing When Conditions Are Detected by DS_RECEIVE. 


Exception Conditions Mae pecs None tony Sale Other Exception 
P Affected Recommendations P Actions 


Code 
DMU specifies multiple destinations, | Dist Copy 1003-001F | Discard the MU. 
but multiple destination traffic is not 
supported. 
Parser exception occurs that tempo- | Dist Copy 
rarily prevents further processing of 
the DMU. 


085C-0001 | Await retry action from 


the sender. 
Exception Conditions detected by the parser when attempting to decode a DCMU. 


Dist Copy | Retry is precluded. Log|100B-000F | Discard the MU. 
the exception, inform 
the operator, and send 
a REMU to the partner. 
Dist Copy | Retry is precluded. 1019-0001 | Discard the MU. 
Log the exception, 
inform the operator, 
and send a REMU to 
the partner. 
Dist Copy | Retry is precluded. Log} 1019-0002 | Discard the MU. 
the exception, inform 
Dist Copy 1019-0003 | Discard the MU. 
|is unable to restart at the indicated 
RBP. (See Note 3) 


the operator, and send 
Exception condition detected by the DSU’s queue service when attempting to fetch a partially received DMU 
the operator, and send 


a REMU to the partner. 
from the mid-MU restart queue. 
Dist Copy 085C-0002 | Await retransmission 
with a new MU_ID. 
a REMU to the partner. 


Exception conditions detected by the DSU, when decoding the control information of the DMU, but before storing 


ithe object. 
A duplicate MU_ID has been Dist Copy 085D-0001 | Discard the MU. 
Dist Copy 085D-0002 | Discard the MU. 


received. 
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Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


Retry is allowed. Log 
the exception, inform 
the operator, and send 
a REMU to the partner. 


The restart_byte_position value is 0. 


The restart_byte_position value is 
greater than one plus the 
last_byte_received value in the 
CRMU. 


The receiver does not support the 
byte-count restart elective and the 
RBP is not the beginning of the LLID 
following the last successfully 
received LLID. 


Retry is precluded. Log 
the exception, inform 
the operator, and send 
a REMU to the partner. 


The byte-count restart elective is 
supported; the RBP # 1; and the 
RBP < /ast_byte_received value 

value in the CRMU, but the receiver 


Retry is precluded. Log 
the exception, inform 


Unable to locate the partially 
received DMU in the mid-MU restart 
queue. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


The MU_ID is above the acceptable 
value. 


Table 6 (Page 4 of 6). Exception Processing When Conditions Are Detected by DS_RECEIVE. 


| Onn Other Exception 
Be por Actions 
Code 
No Code Discard the DCMU. 
cable 
Dist Copy Discard the MU. 
the operator, and send 
a REMU to the partner. 


Dist Copy | Retry is allowed. Log |0812-0011 | Await sender retry 
the exception, inform action. 
the operator, and send 
a REMU to the partner. 
Dist Copy | Retry is allowed. Log |085E-0002 
tially received distribution. (See 
Note 1) 


the exception and send 
Additional exception conditions detected by the DSU when receive-time enhancements are implemented. 


a REMU to the partner. 
801C-0001 


1003-0017 | Discard the MU. 


085B-ssss | Forward the interme- 
diate copies and termi- 
nate the local copies. 
Forward the interme- 
diate copies and termi- 
nate the local copies. 


8019-ssss_ | Forward copies con- 
taining valid dests and 
terminate copies con- 
taining invalid dests. 


What’s 
Affected 


Receiver’s Retry 
Recommendations 


Exception Conditions 


Issue the Send_Error 
verb. No retry or 
reporting actions. 


The DCMU received contained an 
instance number that was less than 
or equal to the current instance 
number. 


Not Appli- 


Retry is precluded. Log 
the exception, inform 


The function requested is not sup- 
ported by this DSU. 


Local resources temporarily unavail- 
able to receive the DMU from the 
partner. 


Discard the partially 
received MU and await 
sender retry action. 


The operator has purged the par- 


Deliver the local copies | 
and terminate the non- 
local copies. 


Log the exception. 
Accept responsibility 

for the dist copy and 

deliver a dist report, to 
the specified DSU/user, 
for the terminated local 
dist copies. 


Hop count has reached 0 and one or | Non-local 
more destinations are non-local. 


This DSU does not provide the 
service level requested. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


Log the exception. 
Accept responsibility 
for the dist copy and 
deliver a dist report to 
the specified DSU/user, 
for the terminated local 
dist copies. 


Local 
Dests 


The agent or server is unknown at 
this DSU and some destinations are 
not local. (If all destinations are 

local, refer to Note 2.) 


Local 
Dests 


Log the exception. 
Accept responsibility 

for the dist copy and 

deliver a dist report to 
the specified DSU/user, 
for the terminated local 
dist copies. 


The agent is not supported for the 
destination DSU or user and some 
destinations are not local. (lf all 
destinations are local, refer to Note 
2.) 


Log the exception. 
Accept responsibility 
for the dist copy and 
deliver a dist report, to 
the specified DSU/user, 
for the terminated dist 
copies. 


Some 
Dests 


No entry was found in the routing 
table that satisfies the destination 
DSU name. 
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Table 6 (Page 5 of 6). Exception Processing When Conditions Are Detected by DS_RECEIVE. 


Exception Conditions What’s Receiver’s Retry Other Exception 
Affected Recommendations Actions 
Code 

Destination user name is unknown Log the exception. 100A-0001 | Terminate the dist 
to the local directory at the destina- Accept responsibility copies for the unknown 
tion DSU, and the directory is for the dist copy and local dests and forward 
exhaustive on the DGN. deliver a dist report, to the remaining valid 

the specified DSU/user, dests. 

for the terminated local 

copies. 


Exception conditions detected by the general server when attempting to write the distribution object. 


0879-0001 | Discard the MU. 

0879-0002 | Discard the MU. 

Dist Copy 0812-0011 | Await sender retry 
action. 

Dist Copy 08A6-0001 | Discard the MU. 


Exception conditions detected by the specific server when attempting to store the object. (Direct Store) 


Local 085B-0001 | Discard the MU 
Dests 


Dist Copy 0854-0000 | Await DCMU from 


sender. 


Retry is allowed. Log 
the exception, inform 
the operator, and send 
a REMU to the partner. 


The storage medium detected a 
temporary failure. The server 
return code was |/O EXCEPTION. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


The storage medium detected a per- 
manent failure. The server return 
code was |/O EXCEPTION. 


Retry is allowed. Log 
the exception, inform 
the operator, and send 
a REMU to the partner. 


Insufficient local resources were 
available to process the object. The 
server return code was TEMPORARY 
SERVER EXCEPTION. 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


The server attempted to write the 
server object, but no server object 
could be found. The server return 
code was OBJECT NOT FOUND 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


Mid-MU restart is 
expected at the LLID 
following the server 
object. Log the excep- 
tion, inform the oper- 
ator, and send a REMU 
to the partner. A 
server report will be 
delivered to the local 
agent. 


The specific-server name specified 
in the distribution is unknown. 


The specific server has detected an 
exception that prevents further 
processing of the server object. The 
server return code was 
SPECIFIC-SERVER EXCEPTION. 


Retry is precluded. Log 
the exception, inform 
the operator, and 
deliver a server report 
to the local agent. 


The specific server has failed to 
back out the server object. 


085A-0000 | Discard the MU. 
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Table 6 (Page 6 of 6). Exception Processing When Conditions Are Detected by DS_RECEIVE. 


SNA 
Report 
Code 


Exception conditions detected by the DSU’s queue service when enqueuing the DMU control block onto the 
router-director queue. 


The storage medium detected a DSU Retry is allowed. Log {0879-0001 | Discard the MU. 


temporary failure. the exception, inform 
the operator, and send 

The storage medium detected a per- | DSU 0879-0002 | Discard the MU. 

manent failure. 

085C-0001 | Await sender retry | 

action. 


a REMU to the partner. 
Queue service encounters a tempo- 
rary exception that prevents further 
processing of this queue. 


Exception condition detected by the DSU when scheduling the DS_Router_Director. 


Retry is precluded. Log} 085C-0002 | Discard the MU. 
the exception, inform 

the operator, and send 
a REMU to the partner. 


What’s Receiver’s Retry Other Exception 


Exception Conditions 


Affected Recommendations Actions 


Retry is precluded. Log 
the exception, inform 

the operator, and send 
a REMU to the partner. 


Retry is allowed. Log 
the exception, inform 
the operator, and send 
a REMU to the partner. 


DSU encounters an exception that 
prevents the scheduling of 


DS_Router_Director. 


Exception conditions detected by the DSU when attempting to process control MUs. 
Parser was unable to decode the Connection | Log the exception and |100B-ssss | Issue Deallocate 
Control_MU from DS_Send. inform the operator. Type(ABEND). 

An exception was encountered when | Connection | Retry is allowed. Log |085C-0001 | Issue Deallocate 
attempting to enqueue the control the exception. Type(ABEND). 
Connection | Retry is allowed. Log | 085C-0001 
the exception and 
inform the operator. 


MU on the control MU queue. 
Connection | Retry is allowed. Log |085C-0001 
the exception and 
-_ 


inform the operator. 
cable 
1018-0005 


1. Because the operator has purged the distribution copy from the receiver’s queue, retry is expected. 


issue Deallocate 
Type(ABEND). 


An exception condition was encount- 
ered when attempting to send a 
control MU. 


Issue Deallocate 
Type(ABEND). 


An exception occurs that prevents 
further processing of this control 
MU. 


The control MU received contained 
an instance number that is below 

the current instance number for the 
MU_ID. 


An RRMU was followed by some- 
thing other than a CHANGE_DIRECTION 
indicator 

(i.€., WHAT_RECEIVED = SEND). 


Discard the control MU. | 


No retry or reporting 
actions. 


Issue Deallocate 
Type(ABEND). 


Retry is precluded. Log 
the exception and 
inform the operator. 


Notes: 


2. In cases where all destinations are local, the receiver may choose to log the exception, inform the operator, 
send a REMU to the partner, and then discard the partially received DMU. 


3. In this exception case, the receiver may reject the DCMU or accept the DCMU by discarding the excessive 
bytes and continuing as normal. 
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Exception Conditions Detected while Performing Routing and Directing 


Table 7 (Page 1 of 2). Exception Processing While Performing Routing and Directing 


SNA 
What’s Reporting Other Exception 
EP epuomeengiren Affected Responsibilities psa Actions 


Exception conditions detected by the DSU’s queue service when reading an entry from the router-director 


queue. 
DSU Log the exception, 0879-ssss_ | Terminate the distrib- 
inform the operator, ution copy. 
and deliver a dist 
report to the specified 
DSU/user. 
Dist Copy |Log the exception, 085C-0001 | Terminate the distrib- 
inform the operator, ution copy. 
and deliver a dist 
report to the specified 
DSU/user. 
Exception conditions detected by the DSU when attempting to route the distribution to the next DSU. 


Hop count is 0 and one or more des-|Non-local {|Log the exception, 801C-0001 | Deliver the local copies 
tinations are non-local. Dests inform the operator, and terminate the non- 
and deliver a dist local copies. 


The storage medium has detected a 
failure. 


The queue service encounters an 
exception that prevents further 
processing of the distribution copy. 


report to the specified 
DSU/user. 


At this DSU, no connection is avail- |Non-local |Log the exception, 8019-0004 | Deliver the local copies 
able for the specified service level. | Dests inform the operator, and terminate the non- 
and deliver a dist local copies. 


report to the specified 
DSU/user. 


No entry was found in the routing Log the exception, 8019-0001 | Forward copies con- 
table that satisfies the DSU name. inform the operator, lor taining valid dests and 
and deliver a dist 8019-0002 | terminate copies con- 
report to the specified taining invalid dests. 
DSU/user. 


Exception conditions detected by the DSU when attempting to perform local delivery at this DSU. 


Local 100A-0001 | Terminate the dist 

Dests copies for the unknown 
local dests and forward 
the remaining valid 
dests. 

Local 085B-0002 | Terminate the dist 

Dests copies for local dests 
and forward the dist 
copies for non-local 
dests. 

Local 100E-0003 | Terminate the dist 

Dests 


Log the exception, 
inform the operator, 
and deliver a dist 
report to the specified 
DSU/user. 


Log the exception, 
inform the operator, 
and deliver a dist 
report to the specified 
DSU/user. 


Log the exception, 
inform the operator, 
and deliver a dist 
report to the specified 
DSU/user. 


Destination user name is unknown 
to the local directory at the destina- 
tion DSU, and the directory is 
exhaustive on the DGN. 


The agent is unknown at this DSU. 


The agent is Known at the DSU, but 
is unavailable. 


copies for local dests 
and forward dist copies 
for the non-local dests. 
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Table 7 (Page 2 of 2). Exception Processing While Performing Routing and Directing © 


; : What’s Reporting Other Exception 
exception Conditions Affected Responsibilities Actions 


The agent is known, but is not sup- | Local Log the exception, 100E-0001 | Terminate the dist 
ported for the user or DSU destina- | Dests inform the operator, or copies for local dests 
| tion. and deliver a dist 100E-0002 | and forward the dist 
report to the specified copies for non-local 
DSU/user. dests. 


Exception conditions detected by the general server when performing auxiliary operations. 


DSU Log the exception, 0879-ssss_ | Terminate the distrib- 
inform the operator, ution copy. 
and deliver a dist 
report to the specified 
DSU/user. 
Dist Copy |Log the exception, 0812-0011 | Terminate the distrib- 
inform the operator, ution copy. 
and deliver a dist 
report to the specified 
DSU/user. 


The server attempted to process the | Dist Copy |Log the exception, 08A6-0001 | Terminate the distrib- 
object, but no server object was inform the operator, ution copy. 
found. The server return code was and deliver a dist 


The storage medium has detected a 
failure. 


Insufficient local resources available 
to process the object. The server 
return code was TEMPORARY SERVER 
EXCEPTION. 


report to the specified 
DSU/user. 


OBJECT NOT FOUND. 


Exception conditions detected by the specific server when performing auxiliary operations. 


Dist Copy |Log the exception and |085B-0001 | At the origin, terminate 
inform the operator. At the auxiliary operation 
the origin, deliver a and terminate the dist 
local report to the origi- copy. At the destina- 

| nator. At the destina- tion, terminate the aux- | 
tion, deliver a dist iliary operation and 


The specific-server name specified 
in the distribution is unknown at this 
DSU. 


purge the distribution 
copy. 
At the origin, terminate 


report to the specified 
DSU/user. 


Dist Copy |Log the exception, 085A-0000 
inform the operator, 
and deliver a specific 
server report to the 
local agent. 


A specific-server exception occurs 
that prevents further processing of 
the distribution. 


the auxiliary operation 
and terminate the dist 
copy. At the destina- 
tion, terminate the aux- 
iliary operation and 
deliver the distribution. 
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Exception Handling for Format Set 1 


This section provides an analysis of exception conditions that can be detected 
in the transport sublayer for FS1 protocols. 


Exception Conditions 
The tables that follow provide an exhaustive list of exception conditions that are 
detected by DS Send and DS Receive in the logical processing order in which 
they could be detected. (The abbreviations used in the tables are explained in 
the following discussion.) The mapping between exception conditions and their 
associated recovery actions is defined within the context of each exception 
occurrence as characterized by: 


1. Which TP detected the exception? 
¢ DS Send: The exception is detected during the sending process. 
« DS Receive: The exception is detected during the receiving process. 


2. Given that an exception is detected by DS_Send or DS_Receive, when is 
that exception detected with respect to the DMU transfer? 


e BT (Before Transfer): Either DS_Send has not yet issued the first 
Send_Data, or DS_Send is issuing LU 6.2 basic conversation verbs but 
the conversation has not yet been allocated (DS_Send is notified by an 
LU 6.2 PS return code). 


¢« DT (During Transfer): The conversation has been successfully allo- 
cated. DS_Send has issued its first Send Data and DS_Receive has 
issued its first Receive _And_ Wait. 


e AT {After Transfer): A complete DMU has been confirmed by the 
receiver, no new transfer has been initiated by the sender, and the con- 
versation is still active. 


3. What is the scope of the exception condition? 


e DMU: The exception condition affects the entire DMU and is unrelated 
to the list of destination users. 


— DMU(A): An LU 6.2 PS exception condition prior to conversation 
establishment will affect the first entry on the appropriate next-DSU 
queue if the retry count is exhausted. 


e ALL Dest: One or more destination users or destination DSUs are 
directly affected by the exception condition, and one or more destination 
users or destination DSUs are unaffected. 


e ALL Dest: All destination users or all destination DSUs, for a particular 
DMU, are affected equally by the exception condition. 


e — (To be determined): A temporary exception condition will not affect 
the DMU (or DSU) unless, after an implementation-defined number of 
retries, the exception condition is considered to be unrecoverable. 


The actions required during retry are specified on the ”“—” line. If retry 
fails, the scope of, and actions for, the resulting permanent exception 
condition are specified on the following line. 
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Note: Whenever all destination users or all destination DSUs are 
affected, the entire DMU is affected. A scope of ALL is distinguishable 
from a scope of the DMU only because ALL implies that the underlying 
exception condition is per destination but, in this case, all destinations 
are affected. 


As a result of implementation choices concerning role, electives, and optimiza- 
tions, the set of FS1 condition codes generated may vary slightly from one 
implementation to another. All implementations must be prepared to receive 
any of the valid FS1 condition codes (including any codes that the implementa- 
tion does not generate). 


Exception Actions 
Exception conditions detected by the transport sublayers exception handling 
procedures result in the following five possible exception actions (the abbrevi- 
ations defined below are used in the following tables): 


e H/R: Hold/release queue 
e Inform the adjacent DSU: 


— SEMU: Send a SEMU. 
— REMU: Send a REMU. 


e Log/Msg: Log and notify operator. 
e Report: Generate a distribution report. 


e Purge: Remove the distribution request from the queue and purge the 
associated object file. 


The tables in this appendix specify the appropriate exception actions for each 
FS1 exception condition occurring in a given context. Every exception action is 
classified by one of the following: 


e N/A: The corresponding exception action is not applicable, given the 
exception condition and retry status, regardless of the exception scope. 


e 0: The corresponding exception action is neither required nor disallowed 
by FS1-defined exception-handling procedures. In these cases, the imple- 
mentation decides whether or not the action will be performed. 


e R: The corresponding exception action is required on behalf of all destina- 
tion users specified in the DMU. 


e R-1: The corresponding exception action is required on behalf of only 
those users directly affected by the exception condition. 


If the set of appropriate actions for a particular exception condition includes 
sending of a distribution report, the exception table specifies the FS1 condition- 
code value that will be encoded into the resulting MU. An exhaustive list of the 
FS1 condition-code values and whether each code is valid in an REMU, Dist_MU 
type status, or both, is specified in Appendix G. 


If the set of appropriate actions for a particular exception condition includes the 


sending of an REMU or SEMU, the exception table specifies the exception class 
that is encoded into the resulting transmission. The exception class for any 
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sender-detected exception has the hexadecimal value C5. The exception class 
for a receiver-detected exception has one of the following values that will be 
used by the sender to determine sender actions: 


e C2 or C3 (syntax or semantic exception, respectively): The nature of this 
class of exceptions is such that sender retry is not likely to succeed. Typi- 
cally, the sender will dequeue the DMU, create a distribution report if 
requested, purge the DMU, log the error, and notify the operator. 


° C4 (processing exception, unrelated to any particular DMU): Sender retry 
is recommended for this class of exceptions. Typically, the sender will hold 
the queues for an implementation-determined time interval, after which 
retransmission is attempted. 


FS1 Exception Conditions Detected by DS_ Send 


Table 8 (Page 1 of 3). FS1 Exception Processing When Conditions are Detected by DS_Send 


FS1 E Exception Actions 
xcp 
Exception Description Cond 
ci | om vada | 


Queue exception conditions when ae an ate from the next-DSU queue. 


I/O device experiences hard- 
ware failure. 


Any queue error occurs in N/A 


the system that prevents raphe 
further processing for this N/A 
DMU (i.e., queue cannot be 

found). 


Builder exception conditions when encoding the command aie of the DMU. 


[orf [os [ow Twa Te [wate fe [a 


LU 6.2 PS exception conditions when ee a conversation with DS_ Receive. 


|LU 6.2 cannot allocate the 
requested conversation at 
this time because either 

there are no available ses- 

sions or LU 6.2 is temporarily 
unable to start an instance of 
DS_ Receive. 


= 


N/A 


2 LA EASES 


OOOF | N/A |DMU(A)| N/A 


LU 6.2 is unable to allocate 
the requested conversation 
because of local or remote 
LU exceptions. 
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Table 8 (Page 2 of 3). FS1 Exception Processing When Conditions are Detected by DS_Send 


| Exception Actions Actions | Exception Actions 
Exception Description eae Scope 


LU 6.2 PS exception conditions when sending one or more DMUs across the conversation. 


BT, | N/A | N/A N/A | N/A 
a sy 

000F 
ad or 


p- | Rk | WAL Nal o 
momen p ep eR 


Parser exception conditions when decoding the REMU. 


Specific-server exception conditions when attempting to read the server object 

Origin server cannot be D 0007 C5 DMU N/A N/A 
found at the origin DSU. 

Origin-server parameters DT 0008 C5 DMU N/A N/A 
were incorrectly specified. | 

Object contents are incom- DT 0006 C5 DMU N/A N/A 
patible with file server. 
| General-server exception conditions when attempting to read the server object. 
General server cannot be DT OOOF C5 DMU 

found at this DSU. 

General-server parameters teak iu 
were incorrectly specified. 


Any server exception occurs bil 
that permanently prevents 

further processing for this 

DMU. 


Specific- or general-server aoe T= I when at the server object. 


rary condition that is 

expected to reset shortly so N/A N/A 
that retransmitting of the 

DMU can be attempted (i.e., 

another process currently 

has the data set open or 

locked). 


I/O device experiences hard- La C5 DMU N/A N/A 

ware failure. 

Specific-server exception conditions mal attempting to decrement the object lock count after i*{* is 
complete. 

Origin server not found at the; AT N/A N/A | DMU N/A N/A N/A N/A N/A 
origin DSU, 


432 SNA/Distribution Services Reference 


Receives an LU 6.2 return 
code of RESOURCE_FAILURE or 
Deallocate Type(ABEND). 


The receiving DSU has vio- 
lated the FS1 protocols 
) regarding usage of LU 6.2. 


ood 


Table 8 (Page 3 of 3). FS1 Exception Processing When Conditions are Detected by DS_ Send 


FS1 Exception Actions 
Exception Description Cond Log 
Origin-server parameters AT N/A N/A DMU N/A N/A N/A N/A N/A 
were incorrectly specified. 
T N/A DMU N/A N/A 


Any server exception occurs A N/A N/A N/A N/A 
that permanently prevents 

further processing for this 

DMU. | 
General-server exception conditions when attempting to decrement the object lock count after transmission is 
General-server parameters AT N/A N/A DMU N/A N/A N/A 

were incorrectly specified. 

that permanently prevents 

further processing for this 

Specific- or general-server exception conditions when decrementing the object lock count after transmission is 
complete. 

Any server error occurs in AT N/A N/A DMU N/A N/A N/A N/A N/A 
the system that temporarily 

prevents further processing 

for this DMU. 

Queue exception conditions when deleting an entry from the next-DSU queue following a successful trans- 

I/O device experiences hard- AT N/A N/A DSU N/A N/A N/A N/A N/A 
ware failure. 

Any queue error occurs in AT N/A N/A DSU N/A | N/A N/A N/A | N/A 
further processing for this 

DMU ({i.e., queue cannot be 


complete. 

Any server exception occurs AT N/A N/A DMU N/A N/A N/A N/A N/A 
DMU. 

I/O device experiences hard- AT N/A N/A DMU N/A N/A N/A N/A N/A 
ware failure. 

mission of a DMU. 

the system that prevents 

found or in-use flag is not 


on). 
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FS1 Exception Conditions Detected by DS_Receive 


Table 9 (Page 1 of 3). FS1 Exception Processing When Conditions Are Detected —-" "ee DS_Receive 


| Exception Actions = Actions 
Exception Description ae ee Log 
Code H/R Msg Report 


LU 6.2 PS exception conditions when allocating a conversation with DS_Send. 


Allocation parameters were BT N/A N/A DSU N/A N/A N/A N/A ial 
incorrectly specified. 


ne niall 


LU 6.2 is unable to allocate 
the requested conversation 
because of other local or 

remote LU exceptions. 


Receives an LU 6.2 return 
code of RESOURCE_FAILURE or 
Deallocate Type(ABEND). 


The sending DSU has vio- 
lated the FS1 protocols 
regarding usage of LU 6.2. 


: 
w) 
® 
a 
BLS 
= 
> 


requested conversation at 
this time because either 
sions or LU 6.2 is temporarily 
unable to start an instance of 
LU 6.2 PS exception conditions when receiving one or more DMUs across the conversation. 
DT or | N/A N/A DSU N/A N/A N/A N/A 
AT 

DSU exception conditions when performing mandatory receive-time checks. 

This DSU does not provide a N/A N/A N/A 
service level specified as 
DSU. 
DSU exception conditions when receiver wishes to temporarily restrict the traffic it accepts based on an 
X’07’. See Appendix G. 
Hop count has reached 0 and DT N/A N/A “ALL N/A N/A N/A N/A N/A N/A 
one or more destination Dest 
users are non-local. C3 N/ 
Destination user name is DT | N/A N/A “All N/A N/A 
unknown to the directory at Dest 


there are no available ses- 
DS_Receive. 

BT, N/A N/A DSU | N/A N/A N/A N/A 

DT, or 

AT 
Structure of the DMU does DT 0004 C2 DMU N/A N/A N/A 
not match Appendix G. 
mandatory for a particular 
implementation-dependent cause. In these cases, the exception object will always be the command, encoded as 
DSU exception conditions when receive-time enhancements are implemented. 
Destination transaction cm | et N/A “ALL N/A N/A N/A N/A N/A N/A 
program is unknown at the Dest 


Note 1) 
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Table 9 (Page 2 of 3). FS1 Exception Processing When Conditions Are Detected by DS_Receive 


FS c Exception Actions 
xcp 
Exception Description Cond Scope 
sg 

Destination DSU name not DT N/A N/A “ALL N/A N/A N/A N/A N/A N/A 
found in routing table, and, Dest 
therefore, next-DSU cannot DT C3 All Dest| N/A N/A N/A 
be determined. 
DSU exception condition when the object size, as perceived by the receiving DSU, exceeds the requested 
capacity service level. 
Server object size is incom- DT 0013 C3 DMU N/A N/A N/A 
patible with capacity level. 


Specific-server exception conditions when receive-time enhancements are supported and direct storing of the 
object, using the destination server, is attempted. 


DT N/A N/A —™ ALL N/A N/A N/A N/A N/A N/A 
Dest 
Cwa | R 


Server specified in the DMU 
is unknown at the destina- 
tion. 


& 
S 
© 


N/A N/A “ALL N/A N/A N/A N/A N/A 
Dest 


/ 


N/A “ALL N/A N/A N/A N/A N/A 
Dest 


General server cannot be D OOOF C4 DMU N/A N/A 
found at this DSU. 

General-server parameters 
were incorrectly specified. 


Any server exception occurs 
that permanently prevents 


Destination-server parame- 
ters were incorrectly speci- 
fied. 


© 
Sis 
5/8 


Object contents are incom- 
patible with file server. 


oO O;o 


further processing for this 
DMU. 


o9/ Oo 
s) 
= 
S 
= 
> 
= 
> 
= 
> 


Specific- or general-server exception conditions when writing the distribution object. 


Temporarily unable to write DT C4 DMU N/A N/A N/A 
due to insufficient capacity. 
has the data set open or 


Server experiences a tempo- DT C4 DMU N/A N/A N/A 
locked). 


rary condition that is 
expected to reset shortly so 

I/O device experiences hard- DT C4 DMU N/A N/A N/A 

ware failure. 

Queue exception conditions when enqueueing the DMU control block onto the router-director queue. 


that retransmitting of the 
I/O device experiences hard- DT C4 DMU N/A N/A N/A 
ware failure. 


DMU can be attempted (i.e., 
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another process currently 


Table 9 (Page 3 of 3). FS1 Exception Processing When Conditions Are Detected ea Fee DS Receive 


E | ss Exception Actions =i Actions 
; xcp 
Exception Description isle Lo 


Any queue error occurs in OOOF N/A N/A N/A 
the system that prevents 

further processing for this 

DMU (i.e., queue cannot be 

found). 


DSU exception conditions when ror |e DS_Router_Director. 


DS_Router_Director is tem- DMU N/A 
porarily unavailable. 


Saas W 7 ba hati bal al 


occurs that prevents the 
Parser exception conditions when decoding a SEMU. 


scheduling of 
The parser is unable to DT N/A N/A DMU N/A N/A N/A N/A | N/A 
decode the SEMU. 


DS_Router_Director. 
Note: 


1. An end-only-role DSU specialized in accepting single-destination traffic is permitted to send a REMU with 
the specified FS1 condition code if a multiple-destination DMU is received. 


Exception Codes for a SEMU (Type FS$1) 
lf DS_Send detects an exception while sending a DMU, DS_Send notifies 
DS Receive by sending a SEMU (Type FS1). The SEMU (Type FS‘) contains the 
exception information pertaining to the condition and indicates to the receiver 
that the remainder of the DMU will not be transmitted. The following table illus- 
trates the exceptions that DS_Send may detect and the corresponding contents 
of the SEMU (Type FS‘). 


Exception Code 


Exception 
Condition 
Code 


Error Condition Sender Action 


Exception 
Class 


Exception 
Object 


System Exception Recoverable 


(See page 


623) 
Insufficient Resource 1B Recoverable 
Storage-Medium Exception (See page | Unrecoverable 
623) 


1B 
07 


Note: Refer to Appendix G, page 623, for a description of the exception code GDS 
values and for the allowable values for the exception object. 


Specific-Server Exception Unrecoverable 


Format Exception Unrecoverable 
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Exception Codes for a REMU (Type FS1) 
lf DS Receive detects an exception while receiving a DMU, DS_ Receive notifies 
DS Send by sending a REMU (Type FS1). The REMU (Type FS1) contains the 
exception information pertaining to the condition and the DSU name of the 
receiver. The following table illustrates the exceptions that DS_Receive may 
detect and the corresponding contents of the REMU (Type FS‘). 


Exception Code 


Exception 
Condition 
Code 


FS1 


Condition Exce ption 
Code 


Error Condition Sender Action 


Exception 
Object 


Exception 
Data 


Dest DSU 
and 
Service 
Parms 
DGN and 
DEN 


Urirecoverable 


Routing Exception 


Unknown User Name 02 09 Unrecoverable 


Hop Count Exhausted 11 09 — Unrecoverable 

Format Exception (See page (See page LLIDF Unrecoverable 
625) 625) Received 

Function Not Supported (See page (See page LLIDF Unrecoverable 
625) 625) Received 


18 
02 


1B 
1A 


Specific-Server Exception Unrecoverable 


Unknown Resource Name - Unrecoverable 
Server 


Invalid Server Parameters 


17 
02 


1A 
09 


Unrecoverable 


Agent TP 


Unknown Resource Name - Unrecoverable 


Agent 


Resource Not Available 04 (See page Recoverable 
625) 

System Exception (See page Recoverable 
625) 

Insufficient Resource 1B Recoverable 

Storage-Medium Exception (See page Recoverable 
625) 


Server Object Size Incompat- 1B Unrecoverable 


ible with Capacity Level 


Note: Refer to Appendix G, page 625, for a description of the exception code GDS values and for the allow- 
able values for the exception object. 
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Appendix F. 


Introduction 


Protocol Boundary Definitions 


The term protocol boundary is used generally to refer to the semantic definition 
of the data and control exchanges between two components in an SNA node. 
This appendix focuses on the protocol boundaries between DS and the applica- 
tion transaction programs that interact with DS. These are the agents that 
request services, the servers that work with DS to fetch and store objects, and 
agents that control the DS operation. 


These protocol boundaries are described generically here in the form of pre- 
cisely defined verbs. IBM products implementing DS do not necessarily provide 
a DS programming interface; however, the DS functions performed by the 
implementations are equivalent to the functions described in this appendix. For 
information about the correspondence between an implementation’s DS func- 
tions and the protocol boundaries described in this appendix, refer to the 
appropriate IBM product publication. For an introductory discussion on the pro- 
tocol boundary, refer to Chapter 1. 


The DS protocol boundary verbs are formally described in verb description 
tables and parameter descriptions. A verb description table contains the 
primary syntax for each parameter associated with a particular verb. A param- 
eter description contains a prose description of the parameter, enumeration 
values, and any conditions of presence associated with a particular parameter. 


Verb Description Table 


Column Descriptions 


Supplied Paramete 


r Name 


The first column of the verb description tables, which begin on page 441, identi- 
fies the parameters supplied on the invocation of a particular verb, and illus- 
trates their hierarchical relationship by indentation of the column entries. For 
example, in the Send_Distribution table on page 449, Report-To_RGN is shown 
indented underneath Report-To_DSU; this shows that Report-To_RGN is a child 
parameter contained by the Report-To_DSU parent parameter. 


Returned Parameter Name 


The returned_parameter name identifies the parameters returned as a result of 
the invocation of a particular verb, and illustrates their hierarchical relationship 
by indentation of the column entries. 


Appendix F. Protocol Boundary Definitions 439 


Parameter Reference Page (Parm Ref Page) 


Length 


Occurrences 


Children 


As syntax is described in the particular verb description table, the semantics, 
enumeration values, and other characteristics are described formally in the 
parameter description. The parameter reference page column in the verb 
description table contains a reference page number to where this parameter 
information is found. 


The range of length values specifies the minimum and maximum lengths of 
parameters that an implementation is required to accept across the protocol 
boundary. Sometimes the length is described as an enumeration (ENUM), 
which means the parameter may be implemented as an integer, character 
string, pointer, or any implementation choice. 


Multiple occurrences of parameters may or may not be permitted. A value of "1 
- <some number>” in this column indicates the allowed range of occurrences 
of the corresponding parameter. A value of ”>1” indicates that there is no 
architecturally defined maximum. A value of ”1” in this column indicates that 
only a single instance of the corresponding parameter is appropriate. A value 
of “0 - 1” indicates that an instance of the corresponding parameter is optional. 


Note: An asterisk denotes special presence rules for a particular parameter. 
These presence rules are detailed in the corresponding parameter description. 


Number (Num): Each parent parameter contains a certain number of different 
children. This column specifies the minimum and maximum number of different 
children for a particular parent parameter. This column also specifies mutual 
exclusion among a set of optional children. If all children are optional (”0-1”) 
and the parent parameter contains "1” for children number, one of the set of 
children occurs within that particular parent. This column does not account for 
multiple occurrences of a particular child within the parent parameter. Multiple 
occurrences of a particular parameter are indicated in the “Occurrences” 
column. , 


Subtable (Subtab): Sometimes the need to divide large tables into subtables 
becomes apparent, particularly when common parameters appear frequently 
within different parameter description tables. This column contains a reference 
page number to the page on which these common parameters are described. 


Parameter Description 


This description is referenced by a page number appearing in the “Parameter 
Reference Page” column corresponding to each parameter in the verb 
description table. The parameter description (see page 487, for example) con- 
tains information pertaining to a particular parameter. Prose descriptions, 
presence rules, enumeration values, and semantics associated with the corre- 
sponding entry in the verb description table may appear in the parameter 
description. 


440  ‘SNA/Distribution Services Reference 


Distribution Verbs 


VERB: Obtain_Local_Server_Report 
Obtain _Local_Server_Report is issued by an agent to obtain a report generated 
by a specific server. It is used for those server reports that can not be returned 
on the normal sequences on Send_Distribution, Receive_Distribution, or 
Query_Distribution Sending. Typically, these are reports of server problems, 
and are not related to a specific distribution. 


Parm ser Oca Children 
Ref | Length | Occurrences 
Receiving_Agent 529 — 
Distribution_Queue_ID 505 482 
528 ~— 
540 ENUM | 
528 32 
549 1-32767 


Queue_Entry_ID 
1. When queue_eniry_/D is used as a supplied parameter, it is not returned. If it is 
not used as a supplied parameter, then it is returned. 


Table 10. Obtain _Local_Server_Report 


Parameter Name 


Return_Code 2 
Queue_Entry_ID 
Specific_Server_Report 


Notes: 


2. If the value of return_code is not ok, then all other expected parameters are not 
returned, except specific_server_report may still be returned. 
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VERB: Query_Distribution_Sending 


Query_Distribution Sending is issued by a sending agent to determine the state 
of the sending operations for the specified distribution. 


This verb is required in several sending sequences and can also be issued ina 


stand-alone sequence when an agent wishes to determine if the distribution has 
been sent. 


Table 11. Query_Distribution_Sending 


Parameter Name Ref | Length 
Page [Nom | Suet 


Supplied Parameter Name 


Distribution ID 04 Jt | ar 


Returned Parameter Name 


Return_Code 
Sending_State 
Specific_Server_Report 
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VERB: Receive_Distribution 


4a4 


Receive_Distribution receives a distribution, either the first one in the specified 
local delivery queue, or a particular one of the distributions in the queue. A 
specific copy of a distribution being received is identified uniquely by three 
parameters. They are the distribution_/D, the distribution_queue_ID, and the 
queue_entry_ID. Supplying distribution _queue_/D retrieves the first entry from 
the specified local delivery queue. Supplying either queue_entry_/D or 
distribution_ID in addition to distribution_queue_!ID retrieves a specific entry 
from the specified local delivery queue. 


Table 12 (Page 1 of 2). Receive_Distribution 


Parm Children 
Ref Length | Occurrences 


529 1-8 1 _— 
505 — 1 482 
504 — 0-1 1 478 
528 32 0-1 2 — 


Parameter Name 


Supplied Parameter Name 


Receiving_Agent 
Distribution_Queue_ID 
Distribution_ID 
Queue_Entry_ID 
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Table 12 (Page 2 of 2). Receive_Distribution 


Parameter Name Ref Length | Occurrences 


Returned Parameter Name 


Return_Code 3 

Dest_Agent 

Distribution_ID 

Agent_Correl 

Service_Parms 

Destination 

Agent_Object 1-32763 

Server 1-8 

Server_Access 1-64 

Server_Object_Byte_Count 8 

Specific_Server_Info 1-32767 

Exception_Report_Req ENUM 

Report-To_DSU — 
Report-To_RGN 1-8 
Report-To_REN 1-8 

Report-To_User — 
Report-To_DGN 1-8 
Report-To_DEN 1-8 

Report-To_Agent 1-8 

Report_Service_Parms — 

Specific_Server_Report 1-32767 

Previously_Received_Date_Time 
Previously_Received_Date 
Previously Received_Time 

Queue_Entry_ID 

Distribution_Time 

Integrity 

Notes: 


1. When distribution_ID is used as a supplied parameter, it is not returned. If it is not 
used as a supplied parameter, it is returned. 


2. When gueue_entry_!D is used as a supplied parameter, it is not returned. If it is 
not used as a supplied parameter, it is returned. 


3. If the value of return_code is not OK, then all other expected parameters are not 
returned. 
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VERB: Receive_Distribution_Report 
Receive_Distribution Report is issued by a specially started instance of the 
report-to agent (which will often have defaulted to the origin agent) to receive a 
report on the DS condition of a distribution. A distribution report being received 
is identified uniquely by three parameters. They are the distribution_/D, the 
distribution_queue_ID, and the queue_entry_ID. Supplying | 
distribution_queue_!D retrieves the first entry from the specified local delivery 
queue. Supplying either queue_entry_/ID or distribution_ID in addition to 
distribution_queue_/D retrieves a specific entry from the specified local delivery 
queue. : 


|Table 13 (Page 1 of 2). Receive_Distribution_Report 


ram] —ehitsren 
Ref Length | Occurrences 
Page Num | Subtab 


529 in 
505 
504 
528 


Parameter Name 


Supplied Parameter Name 


Receiving Agent 
Distribution_Queue_ID 
| Distribution_ID 

Queue_Entry_ID 
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Table 13 (Page 2 of 2). Receive_Distribution_Report 


Parameter Name 


Returned Parameter Name 


Return_Code 3 
Report-To_Agent 
Distribution_ID 
Service_Parms 
Reporting _DSU 
Reporting RGN 
Reporting REN 
Report_Date 
Report_Time 
Agent_Correl 
Report-To DSU 
Report-To_RGN 
Report-To_REN 
Report-To_User 
Report-To_DGN 
Report-To_DEN 
Receiving DSU 
Receiving RGN 
Receiving_REN 
Previously Received_Date_Time 
Previously _Received_Date 
Previously_Received_Time 
Queue_Entry_ID 
Reported-On_Time 
Reported-On_Dest_Agent 
SNA_Condition_Report 
Integrity 
Notes: 


Parm Children 
Ref Length | Occurrences 
Page [Num | Subteb 


—_ 


—_ j= w= awash ox iach 2 ij wh ooh 


1. When distribution_ID is used as a supplied parameter, it is not returned. 


2. When queue_entry_!ID is used as a supplied parameter, it is not returned. 


3. If the value of return_code is not oK, then all other expected parameters are not 


returned. 
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VERB: Receiving_Sequence_Completed 
Receiving Sequence_Completed completes the transfer of responsibility from 
the DSU to the agent on a receiving sequence. This verb can be used to follow 
up either a Receive_Distribution or a Receive_Distribution_Report. 


Table 14. Receiving _Sequence_Completed 


Ref {| Length | Occurrences 
Supplied Parameter Name 
Distribution _Queue_ID 505 482 
Queue_Entry_ID §28 — 


Returned Parameter Name 


Retumcode 540 fenum | Ot | — | 


Parameter Name 
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VERB: Send _Distribution 
Send_Distribution initiates a distribution within a DS network. In high-integrity 
verb sequences, the sequence number and date must be supplied. The 
methods of specifying destinations are: 


1. The originating agent may choose to specify one or more users in the desti- 
nation parameter. If so, the DSU determines for each user the DSU to 
which the distribution should be sent. 


2. The originating agent might specify one or more DSUs as destinations. If 
so, the distribution service has no need to determine what DSU to send it 
to, either at the origin or as it travels through the network. 


The originating agent may choose to specify a mix of (1) and (2). 


Table 15 (Page 1 of 2). Send_Distribution 


Parm | Children | 
Parameter Name Ref Length | Occurrences 
Page aay Subtab 


Supplied Parameter Name 


Distribution_ID 
Agent_Correl 
Service_Parms 
Exception_Report_Req 
Report-To_DSU 
Report-To_RGN 1-8 
Report-To_REN 1-8 
Report-To_User — 
Report-To_DGN 1-8 
Report-To_DEN 1-8 
Report-To_Agent 1-8 
Report_Service_Parms — 
Dest_Agent 1-8 
Destination = 
Agent_Object 1-32763 
Server 1-8 


Server_Access 1-64 
Specific_Server_Info 1-32767 
Server_Object_Byte_Count 8 
Integrity ENUM 
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Table 15 (Page 2 of 2). Send_Distribution 


Parm 


Parameter Name Ref | Length | Occurrences 


Returned Parameter Name 
Return_Code 


Seqno_To_Clean_Up 


Clean_Up_Seqno 

Clean_Up_Date 

Sending_State ENUM 
Sending_State ENUM 
Specific_Server_Report 1-32767 
Distribution_Time |— 


VERB: Sending_Sequence_Completed 
Sending Sequence_Completed is used only on high-integrity sequences after 
the agent has learned that the DSU has accepted responsibility for the distrib- 
ution. After Sending _Sequence_Completed has been issued, the DSU may then 
purge its awareness of the distribution when it has completed sending. 


Table 16. Sending _Sequence_Completed 


Parm | 


Ref | Length | Occurrences 

Page | Num | Subtab 
Supplied Parameter Name 
Distribution_1D ee =a BRE Ba SR 


Returned Parameter Name 


Return.code 540 fenum | | — | 


Parameter Name 
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Operations Verbs 


VERB: Add_DSU_Data 


Add DSU _ Data adds a new row to a system data structure. 


Table 17. Add_DSU_Data 


Parm Children 
Parameter Name Ref Length | Occurrences 
Peg [Num | Subtey 


Supplied Parameter Name 


Data_Structure 
New_Row 


Agent_List_Entry 
Connection_Definitions_Entry 
Directory_Entry 
DSU_Definition_Entry 
Intervention_List_Entry 

| MU_ID_Registry_Entry 
Next-DSU_Queue_Definitions_Entry 
Routing _Table_Entry 
Server_List_Entry 


Returned Parameter Name 


Retumcode 540 ENUM | Ot | | 
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VERB: Get_Distribution_Info 


Get_Distribution_Info gives all the distribution control information for a specified 
distribution. The specified distribution may be in any of the DSU’s queues. 


Table 18. Get_Distribution_Info 


Parameter Name Ref Length | Occurrences 
Page | Num Subtab 


Supplied Parameter Name 

Queue_ID 529 

fmcooyo fawn daz | sf | 
Returned Parameter Name 

Return_Code ! 


Distribution_ID 
Agent_Correl 


Service_Parms 
Destination 


Dest_Agent 
Agent_Object 
Server 
Server_Access 
Server_Object_Byte_Count 
Specific_Server_Info 
Exception_Report_Req 
Report-To_DSU 
Report-To_RGN 
Report-To_REN 
Report-To_User 
Report-To_DGN 
Report-To_DEN 
Report-To_Agent 
Report_Service_Parms 
Hop_Count 
Specific_Server_Report 


1-8 
1-32763 
1-8 
1-64 

8 
1-32767 
ENUM 
1-8 

1-8 

1-8 

1-8 

1-8 

4 
1-32767 


Previously_Received_Date_Time 
Previously_Received_Date 
Previously_Received_Time 

Distribution_Time 

integrity 

MU_ID 

Note: 


1. If the value of return_code is not ok, then all other expected parameters are not 
returned. 
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VERB: Get_Distribution_Log Entry 
Get_Distribution_ Log Entry obtains a message (DTMU) recorded by a DSU in 
the distribution log. 


Table 19. Get_Distribution_Log Entry 


Parameter Name Ref Length | Occurrences 
Page Num Subtab 


Supplied Parameter Name 


Recmrettn,simier aw fe || | 
Requested_Entry_Number 538 — 
Returned Parameter Name 
Return_Code ! 
Number_Of_Matching_Entries 
Logging_Date 
Logging_Time 
Program_Name 
Session_Reference 
Net_ID 
LU _Name 
Mode_Name 
Direction 


Accessed_Queue_ID 
Product_Specific_Data 
Distribution_ID 

MU_ID 

Destination 


Distribution_Log Data 
Note: 


1. If the value of return_code is not OK, then all other expected parameters are not 
returned. 
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VERB: Get_Exception_Log_Entry 
Get_Exception_Log Entry returns the exception information recorded in the 
exception log. 


Table 20. Get_Exception_Log_Entry 


Parameter Name Ref | Length | Occurrences 


Supplied Parameter Name 


Distribution_ID 504 478 
Requested_Entry_Number 538 i o— 


Returned Parameter Name 


Return_Code 1 
Number_Of_Matching_Entries 
Logging_Date 
Logging_Time 
Program_Name 
Session_Reference 

Net_ID 

LU_Name 

Mode_Name 

Direction 
Accessed_Queue_!D 
Product_Specific_Data 
Distribution _ID 
| SNA_Report_Code 
MU_ID 
Reported-On_Destination 
Exception_Log Data 
Note: 


1-32767 


1. If the value of return_code is not OK, then all other expected parameters are not 
returned. 


VERB: Hold_Distribution_Copy 


Hold_Distribution_Copy holds a specified distribution copy on a specified queue. 


Ref | Length | Occurrences 

rs om [se 
Supplied Parameter Name 
Queue_ID 
Queue_Entry_ID 


Returned Parameter Name 


Returncode S40 feNuM || — | 


Table 21. Hold_Distribution_Copy 


Parameter Name 
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VERB: List_Adjacent_DSUs 
List_Adjacent_DSUs lists the names of all DSUs that are shown in the routing 


table as being adjacent to the specified DSU. 


Table 22. List_Adjacent_DSUs 


Pare [ehissren 
Parameter Name Ref | Length | Occurrences 
_ om | St 


Supplied Parameter Name 


service pamms sav), J] ot 2 | ats 
Returned Parameter Name 


Returned Parameter Name 
540 ENUM 1 
487 ~— 0-64 
488 1-8 1 
1-8 1 


Return_Code 

Adjacent_DSU 
Adjacent_RGN 

Adjacent_REN 
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VERB: List_Connections 
List_Connections returns the connection names and their send/hold states for 
one or more connections. Connections can be specified individually by LU and 
mode, or collectively for all connections to an adjacent DSU. Connections can 
also be specified by a destination DSU, optionally qualified by service parame- 


Ref | Length | Occurrences 
Page p Num Subtab 


ters. 


Table 23. List_Connections 


Parameter Name 


Supplied Parameter Name 


Connection 
Net_ID 
LU_Name 
Mode_Name 

Route 

Dest_DSU 
Dest_RGN 
Dest_REN 

Service_Parms 


Returned Parameter Name 


Return_Code 


Connection 
Net_ID 
LU Name 
Mode_Name 
Hold_State 


Note: 
1. The connection and route supplied parameters are mutually exclusive. 
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VERB: List_Control_MU_Queue 


List_Control_ MU Queue lists all control MUs present in a specified queue. 


Table 24. List_Control_MU_Queue 


Parm ree 
Parameter Name Ref | Length Pecan um 
Page 


Supplied Parameter Name 
Net_ID 
LU_Name 
Mode_Name 
Direction 
Starting_Queue_Entry_ID 
Returned Parameter Name 
Return_Code 
Control_Info 
MU_Type 
MU_ID 
Queue_Entry_ID 
Next_Queue_Entry_ID 


VERB: List_Conversations 
List_Conversations lists the active conversations, both sending and receiving, 
for a specified connection or group of connections. 


Table 25. List_Conversations 


Parameter Name Ref Length | Occurrences 
__| Page Num | Subtab 


Supplied Parameter Name 


Connection | 496 
Net_ID 517 
LU_Name _ 512 
Mode_Name 913 


Returned Parameter Name 


Return_Code 


Conversation_Info 
Net_ID 
LU_Name 
Mode_Name 


Conversation_ID 
Direction 
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VERB: List_Distributions_Being_Received 


List_Distributions_Being Received lists the distribution control information for 
distributions being received on a specified connection. Optionally, the verb can 
request the number of bytes already received by the server. 


Table 26. List_Distributions_Being Received 


| Children 
Parameter Name Length | Occurrences 
[ om | 


Supplied Parameter Name 
Connection 


Net_ID 
LU _Name 


Mode_Name 
Server Bytes Received 
Returned Parameter Name 
Return_Code | 
Distribution_Info 

Distribution _ID 

Distribution_Time 

Received_Server_ Bytes 


VERB: List_Distributions_Being_Sent 


List_Distributions_Being_Sent lists the distribution control information for dis- 
tributions being sent on a specified connection. Optionally, the information can 
be expanded to report the number of server object bytes yet to be sent. 


Table 27. List_Distributions_Being_ Sent 


Parm 


Parameter Name Ref | Length | Occurrences 
re i 


Supplied Parameter Name | 
1-8 
1-8 
1-8 
ENUM 


Connection 
Net_ID 
LU Name 
Mode_Name 
Server Bytes Remaining 
Returned Parameter Name 
Return_Code 
Distribution _Info 
Distribution _1D 
Distribution Time 
Remaining, Server_Bytes 
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VERB: List_DSU_Data 


List_DSU_Data is used to display to the operator the value of one or more rows 
of a system data structure. 


Table 28. List_DSU_Data 


Parm 


Parameter Name Ref | Length | Occurrences 
Ll pry 


Supplied Parameter Name 


Data_Structure 

Row_ Selection Criteria 
Agent_List_Entry 
Connection_Definitions_Entry 
Directory_Entry 
DSU_Definition_Entry 
intervention _List_Entry 
MU_ID_Registry_Entry 
Next-DSU_Queue_Definitions_Entry 
Routing_Table_Entry 
Server_List_Entry 

Column_To_Be_ Listed 

Starting Row_Number 


Return_Code 

Selected_Row 
Agent_List_Entry 
Connection_Definitions_ Entry 
Directory_Entry 
DSU_Definition_Entry 
intervention_List_Entry 
MU_ID_Registry_Entry 
Next-DSU_Queue_Definitions_ Entry 
Routing_Table_Entry 
Server_List_Entry 

New_Row_Number 
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VERB: List_Queue_Entries 
List_Queue_ Entries lists the distributions, the distribution reports, and server 
reports for a specified queue. 


Table 29. List_Queue_Entries 


Parameter Name Ref | Length | Occurrences 


Supplied Parameter Name 


Queue_ID 
Queue_Entry_Type 
Distribution_ID 
Querying Agent 
After_Date 
After_Time 
Before_Date 
Before_Time 


Starting_Queue_Entry_ID 


Returned Parameter Name 


Return_Code 
Distribution_Info 
Distribution_ID 
Queue_Entry_ID 
Queue_Entry_Type 
Distribution_Time 
Previously _Received_Date_Time 
Previously_Received_Date 
Previously Received_Time 
Hold_State 
Next_Queue_Entry_ID 
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VERB: List_Queues_Containing_Distribution 
List_ Queues Containing Distribution lists the queue identifiers of all queues 
that contain a copy of the specified distribution. 


Table 30. List_Queues Containing Distribution 


Parm Children 
Parameter Name Ref Length | Occurrences 


Supplied Parameter Name 


DistributiontD 504 Tt 8 | a8 


Returned Parameter Name a 

Return_Code 540 ENUM 1 — 
pene ae J | owe | | 
Note: 


1. If the value of return_code is not oK, then all other expected parameters are not 
returned. 
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VERB: Modify DSU_Data 


Modify_DSU_Data changes the value of one or more rows in a system data 
structure. This verb must be used for parameters that must always exist, such 
as the DSU name. It may also be used to modify an existing list entry. 


Table 31. Modify_DSU_Data 


Parm | Children | 
Parameter Name Ref | Length | Occurrences 
Page [Mur | Subtab 


Supplied Parameter Name 
Data_Structure 
Row_Selection_Criteria 
Agent_List_Entry 
Connection _Definitions_Entry 
Directory_Entry 
DSU_Definition_Entry 
Intervention _List_Entry 
MU_ID_Registry_Entry 
Next-DSU_Queue_Definitions_Entry 
Routing _Table_Entry 
Server_List_Entry 
Modified_Row 
Agent_List_Entry 
Connection_Definitions_Entry 
Directory_Entry 
DSU_Definition_Entry 
intervention _List_Entry 
MU_ID_Registry_Entry 
Next-DSU_Queue_Definitions_Entry 
Routing_Table_Entry 
Server _List_Entry 
if_Nonunique_Key 


Retun code ——SSSSS~*dSO Je Td 
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VERB: Purge_Queue_Entry 


Purge_Queue Entry deletes a queue entry from a specified queue and causes 
appropriate reporting. 


Table 32. Purge_Queue_Entry 


Parm | Children 
Parameter Name Ref | Length | Occurrences 
ne om |S 


Supplied Parameter Name 


Queue _ID | 529 
Queue_Entry_ID 528 


Returned Parameter Name 


Return_code 540 ENUM || | 


VERB: Release_Distribution_Copy 


Release_Distribution_Copy releases a specified distribution copy on a specified 


queue. 


| Table 33. Release_Distribution_Copy 
pall 


Parameter Name 
| | page 


Length | Occurrences 
ie 
Supplied | Parameter Name 
Queue _ID 
Queue_Entry_ID 


Returned Parameter Name 


aaa NC a 
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VERB: Remove_DSU_Data 


Remove_DSU_Data removes one or more rows from a system data structure. 


Table 34. Remove_DSU_Data 


Parameter Name Ref | Length 4 Occurrences 
rage [Nm | Sub 


Supplied Parameter Name 


Data_Structure 

Row_Selection_Criteria 
Agent_List_Entry 
Connection_Definitions_Entry 
Directory_Entry 
DSU_Definition_Entry 
Intervention_List_Entry 
MU_ID_Registry_Entry 
Next-DSU_Queue_Definitions_Entry 


Routing_Table_Entry 
Server_List_Entry 


if, Nonunique_Key 
Returned Parameter Name 


Returncode 540 feNUM | Ot | — | 


VERB: Reroute_Distribution_Copies 


Reroute_Distribution Copies reroutes one or more distribution copies found in a 


specified queue. 
Parm Children 
Ref | Length | Occurrences 
Page Num | Subteb | 


Table 35. Reroute_Distribution_Copies 


Parameter Name 


Supplied Parameter Name 


Connection 
Net_ID 
LU_Name 
Mode_Name 

Distribution_ID 

Service_Parms 


Returned Parameter Name 


Return_Code 
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VERB: Reset_MU_ID_Registry 
Reset_MU_ID_Registry causes the MU_ID registry for a connection to be resyn- 
chronized. Issuing this verb causes a Reset Request MU to be sent on the 
specified connection. 


Table 36. Reset_MU_ID_ Registry 


Parameter Name Ref Length | Occurrences 


Supplied Parameter Name 


Connection 

Net_ID 

LU_Name 

Mode_Name 
Next_MU_ID 
Returned Parameter Name 


Return_Code 


VERB: Start_Connection 
Start_Connection activates a connection by causing the persistent sessions, if 
any, to be bound, setting the DS_Send control values, and checking that the 
appropriate routing segments are in the active state. 


Ref Length | Occurrences 
Page p Nur | Subtab 


Table 37. Start_Connection 


Parameter Name 


Supplied Parameter Name 


Connection 
Net_ID 
LU_Name 
Mode_Name 
Max_DS_Sends 
Max_DS_Receives 


Returned Parameter Name 


Retumcode 540 enum | ot | ~ | 
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VERB: Terminate_Connection 
Terminate_Connection terminates a connection by terminating all active conver- 
sations on it. 


Table 38. Terminate Connection 


Table 38. Terminate Connection 
pak at | tents fone Children 
- Parameter Name Length | Occurrences 
Num | Subtab 
1-8 
1-8 : 
1-8 
ENUM 
Returned Parameter Name 
[ReturnCode sO eNUM | ot | — | 


VERB: Terminate_Conversation 
Terminate_Conversation terminates a conversation. 


Table 39. Terminate_Conversation 


Parm | Children | 
Parameter Name Ref | Length | Occurrences 
rs som [ se 
Supplied Parameter Name 
Conversation_ID 497 4 
MU_Action | 514 ENUM | 


Returned Parameter Name 


ReturnCode 54 ENUM || — | 
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Server Verbs 


VERB: Assign_Read_Access 


Assign_Read_Access creates entries in the access list. Any process that has 
been assigned read access to a particular server object can issue this verb. 
The issuer of the verb is identified in each entry as the assigning process. 
When the assigning and the assigned-to processes are the same, the entry is 
called a self assignment. When they are different, the entry is called an other 
assignment. Typically, a process will issue this as soon as it has been given an 
access descriptor to confirm access and to create its own self-assignment 
entry. DS does this before returning control on a Send_Distribution verb. 


Every time this verb is issued, an entry is created and it is the responsibility of 


the assigning process to eventually issue a Release_Read_Access to delete the 
entry. The access list may contain multiple entries with the same contents. 


Table 40. Assign _Read_Access 


Perm Chiron 
Parameter Name Ref | Length | Occurrences 
Page [Mum | Subtab 


Supplied Parameter Name 


Assigning_Process 

Current_Unit_Of_Work_ID 
Distribution_ID 
Agent_Unit_Of_Work_ID 


Assigned_Process 

New_Unit_Of_Work_ID 
Distribution_ID 
Agent_Unit_Of_Work_ID 

Assign_Unit_Of_Work_ID 

Server 

Server_Access 

Returned Parameter Name 


[Retuncode 540 fenum ft | — | 
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VERB: Backout_Server_Object 
Backout_Server_Object Informs the server that it should back out a server 
object that has been successfully written, because the distribution will not be 
delivered. 


Table 41. Backout_Server_Object 


Parameter Name 


Ref Length | Occurrences 


1-8 
1-8 
1-64 
1-32767 
1-32767 


Supplied Parameter Name 


538 
545 
545 
549 
549 


Requesting Process 
Server 


Server_Access 


Specific_Server_Report 


Specific_Server_Info 


Returned Parameter Name 


Return_Code 540 ENUM 
Specific_Server_Report 549 1-32767 
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VERB: Initiate_Read 


Initiate_ Read creates and initializes the control block used during the reading of 
the server object. 


Table 42. Initiate_Read 


Parameter Name Ref Length | Occurrences 


Supplied Parameter Name 


Requesting Process 
Server 
Unit_Of_Work_ID 
Distribution_!D 
Agent_Unit_Of_Work_ID 1-256 
Agent_Correl 1-128 
Agent_ Object 1-32763 
Specific_Server_Info 1-32767 
Server_Access 1-64 
Restartability ENUM 
Restart_ID — 
Net_ID 1-8 
LU_ Name 1-8 
Mode_Name 1-8 
MU_ID 4 
Restart_Byte , 8 
Returned Parameter Name 


Return_Code | 540 ENUM 1 
Server_Instance_ID 546 4 1 
Specific_Server_Report 549 1-32767 0-1 


Note: 


1. If the value of return_code is not ox, then all other expected parameters are not 
returned, except specific_server_report may still be returned. 
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VERB: Initiate_Write 
Initiate_Write creates and initializes the control block used during the writing of 
the server object. An exclusive-write lock is set to indicate that no reading, 
other writing, or deletion may take place. 


As long as the exclusive-write lock for an object is set, no read access can be 
assigned. Thus, any Assign_Read_ Access issued while the exclusive-write lock 
is set results in an error condition. 


Table 43. Initiate_Write 


Parameter Name 


eeurrences [Num | Subtab 


Parm 
Ref | Length 
Page 


Supplied Parameter Name 


Requesting Process 
Server 
Server_Object_Byte_Count 
‘Unit_Of_Work_ID 


Distribution_ID 

Agent_Unit_Of_Work_ID 1-256 
Agent_Correl 1-128 
Agent_Object 1-32763 
Restartability ENUM 
Restart_ID — 

Net_ID 1-8 

LU_Name 1-8 

Mode_Name 1-8 

MU_ID 4 
Restart_Byte 8 


Returned Parameter Name 


Return_Code | 


Server_Instance_ID 


Specific_Server_Report 


il REG 
546 |4 

549 1-32767 

Note: | 


1. If the value of return_code is not ok, then all other expected parameters are not 
returned, except specific_server_report may still be returned. 
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VERB: Query_Last_Byte_Received 


VERB: Read 


Query_Last_Byte_ Received returns the last byte that was successfully written 
by the server. 


Table 44. Query_Last_Byte_ Received 


Parm Children 
Parameter Name Ref | Length | Occurrences 
a om [8 


Supplied Parameter Name 


Requesting_Process 
Server 
Restart_ID 
Net_ID 
LU_Name 
Mode_Name 
MU_ID 
Returned Parameter Name 


Return_Code 1 ENUM 1 
Last_Byte_ Received 8 1 
Note: 


1. If the value of return_code is not oK, then all other expected parameters are not 
returned. 


Read returns a contiguous stream of bytes as a part of the server object. 


Ref | Length | Occurrences 
Buffer 


545 1-8 

493 8 

492 1-32767 
Returned Parameter Name 


Return_Code 540 ENUM 
Data_Length 498 8 


Table 45. Read 


Parameter Name 


Supplied Parameter Name 


Server 
Server_Instance_ID 
Buffer_Length 
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VERB: Release_Read_Access 
Release_Read_Access is issued by an assigning process to cause an entry to 
be deleted from the access list. It must be issued once for every 
Assign _Read_Access that the assigning process has issued, including the 
Assign_Read_Access implied by the Terminate_Write verb. Typically, a process 
will delete its self-assignment entry only after assigning read access to another 
process. It will delete its other-assignment entries only after the assigned-to 
process has had an opportunity to create its self-assignment entry. When all 
access list entries are deleted, the server will delete the object. 


Table 46. Release_Read_Access 


Children 


Length | Occurrences | Num | subtab 


Parameter Name 


Supplied Parameter Name 


Assigning_Process 

Unit_Of_Work_ID 
Distribution_ID 
Agent_Unit_Of_Work_ID 

Assigned_Process 

Server 

Server_Access 


Returned Parameter Name 


Retumcode 540 ENUM | Ot | | 


VERB: Terminate_Read 
Terminate_Read deallocates the control block used during the reading of the 
server object. 


Table 47. Terminate_Read 


Parm 
Ref | Length | Occurrences 
Page | 


Biel gis 
546 4 1 

554 ENUM 1 

Returned Parameter Name 

tf sero | ov | =| = 
Specific_Server_Report 549 1-32767 


Parameter Name 


Supplied Parameter Name 
Server 
Server_Instance_ID 
Termination_Type 
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VERB: Terminate_Restartability 
Terminate_Restartability informs the server that the identified server object will 
not be restarted. (That is, no Initiate _Write or Initiate _Read verbs using the 
restart_byte parameter will be issued.) 


Table 48. Terminate_Restartability 


Parameter Name 


Ref Length | Occurrences 
os om [st 


Supplied Parameter Name 


Requesting Process 


Server 
Restart_ID 
Net_ID 
LU_Name 
Mode_Name 
MU_ID 
Returned Parameter Name 


Return_Code 540 ENUM 
Specific_Server_Report 549 1-32767 


VERB: Terminate_Write 
Terminate_Write deallocates the control block used for the writing of the server 
object, releases the exclusive-write lock, and generates the first entry in the 
read access list. This entry is a self-assignment entry for the requesting 
process that issued the Initiate_Write and contains the unit of work specified on 
that verb, if any. 


Table 49. Terminate_Write 


Parameter Name Ref Length | Occurrences 


Supplied Parameter Name 


Server 545 1-8 
Server_Instance_ID 546 4 
Termination_Type 554 ENUM 


Returned Parameter Name 


Return_Code ENUM 
Specific_Server_Report 1-32767 


Server_Access 1-64 
Specific_Server_Info 1-32767 
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VERB: Write 


Subtables 


Write passes to the server a part of a server object. 


Ref Length 
rae es [sain 
Data_Length 


545 1-8 

546 4 

492 1-32767 

498 8 
Returned Parameter Name 


Retuncode 540 enum | ot | = | 


Table 50. Write 


Parameter Name 


Supplied Parameter Name 


Server 


Server_Instance_ID 
Buffer 


SUBTABLE: Agent_List_Entry 


Table 51. Agent_List_Entry 
Parm 


Parameter Name Ref | Length ae, 


Agent_List_Entry | 
Agent | 489 1-8 
Local_Queue_Type ENUM 
Local_Info 510 1-64 


Notes: 


1. The agent_list_entry parameter is supplied on Add_DSU_ Data, List_DSU_Data, 
Modify_DSU_Data, and Remove_DSU_Data. 


It is returned on List_DSU_Data. 


2. When agent_list_entry occurs as a child of row_se/ection_criteria or selected_row, 
any children of agent_list_entry may be used for selection, therefore nullifying the 
occurrences column. 


474 SNA/Distribution Services Reference 


SUBTABLE: Connection_Definitions_Entry 


Table 52. Connection_Definitions_Entry 


Parm 


Ref Length Sm 


Parameter Name 


Connection_Definitions Entry | 
Net_ID 
LU_Name 
Mode_Name 
Direction 
Max_DS_Sends 
Max_DS_Receives 


Data_Stream_Format 
Year 3 
Month 3 
Day 3 

Hours 3 
Minutes 3 
Seconds 3 
Hundredths 2 
Local_Or_GMT_Flag 2 
Notes: 


1. The connection_definitions_entry parameter is supplied on Add_DSU_Data, 
List_DSU_Data, Modify_DSU_Data, and Remove_DSU_Data. 


It is returned on List_DSU_Data. 


. When connection_definitions_entry occurs as a child of row_selection_criteria or 
selected_row, any children of connection_definitions_entry may be used for 
selection, therefore nullifying the occurrences column. 


3. The date and time parameters indicate the last time the MU_ID Registry was reset 
for this connection. This is the date and time that appeared in the RRMU. 
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SUBTABLE: Date 


Table 53. Date 


Parameter Name 


Parm 
Ref Length a Ss 
Page 


Note: 


1. A date is supplied, as after_date and before_date, on List_Queue_Entries. 


It is returned on Get_Distribution_Info (previous/y_received_date), 
Get_Distribution_Log_Entry (/ogging_date), Get_Exception_Log_ Entry 
(logging_date), List_Queue_Entries (orevious/y_received_date), 
Receive_Distribution (orevious/y_received_date), Receive_Distribution_Report 
(report_date, previous/y_received_date), and Send_Distribution (c/ean_up_date). 


It is also found in the distribution_identification subtable as origin_date. 


SUBTABLE: Destination 


Table 54. Destination 


Parm 


Parameter Name Ref | Length | Occurrences 
bd ae Subtab 


Destination | 
Dest_DSU 
Dest_RGN 
Dest_REN 
Dest_User 
Dest_DGN 
Dest_DEN 
Note: 


1. The destination parameter is supplied on Send_Distribution. 


It is returned on Get_Distribution_Info, Get_Distribution_Log_ Entry, and 
Receive_Distribution. 
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SUBTABLE: Directory_Entry 
Table 55. Directory_Entry 


Parameter Name 


Parm 
Ref Length | Occurrences 
Page 


Directory_Entry ! 
DGN 
DEN 
Agent 
RGN 
REN 
Local_Queue_Type 


Local_Info 
Next_Seqno 


Notes: 


1. The directory_entry parameter is supplied on Add_DSU_Data, List_DSU_Data, 
Modify_DSU_Data, and Remove_DSU_Data. 


It is returned on List_DSU_Data. 


2. When directory_entry occurs as a child of row_se/ection_criteria or se/ected_row, 
any children of directory_entry may be used for selection, therefore nullifying the 
occurrences column. 


3. The DGN and DEN must be specified as a pair. The agent, the DEN, or the DGN 
and DEN may be specified with a system-specific value that matches any token for 
default directing. 


4. Agiven entry contains either RGN and REN or /ocal_queue_type and next_seqno; 
however, an entry never contains both pairs of parameters. An entry that con- 
tains /ocal_queue_type and next_seqno may also contain /ocal/_info. 
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SUBTABLE: Distribution_ID 
Table 56. Distribution_ID 


Parameter Name Ref {| Length | Occurrences 
Page j Num | Subtab | 


Distribution_ID 1 
Origin _DSU — 0-1 3 — 
Origin_RGN | 1 
Origin_REN | 
Origin_User 
Origin_DGN 
Origin_DEN 
Origin_Agent 


Origin_Seqno 


Origin_Date 


Notes: 


1. The distribution_identification parameter is supplied on Assign_Read_Access, 
Get_Distribution_Log Entry, Get_Exception_Log_ Entry, Initiate_Read, 
Initiate_Write, List_Queue_Entries, List_Queues_Containing_Distribution, 
Query_Distribution_Sending, Receive_Distribution, Receive_Distribution_Report, 
Release_Read_Access, Reroute_Distribution_Copies, Send_Distribution, and 
Sending_Sequence_Completed. . : 


It is returned on Get_Distribution_Info, Get_Distribution_Log Entry, — 
Get_Exception_Log_ Entry, List_Distributions_Being_ Received, 
List_Distributions Being Sent, List_Queue_Entries, Receive_Distribution, and 
Receive_Distribution_Report. 


2. The number of children of distribution_identification is shown on some verbs as 
1-5. On these verbs, any of the children of distribution_identification may be used 
as selection criteria. 


3. The origin_DSU will always be present in a distribution_identification except in two 
cases: 


¢ The distribution_identification is being used as a selection criteria, as 
described in Note 2. 


¢ The distribution_identification was transported in an FS1 Dist_MU type REPORT. 
In this case, origin_user will always be present. | 
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SUBTABLE: DSU_Definition_Entry 
Table 57. DSU_Definition_Entry 


Parameter Name Ref Length | Occurrences 
Page Num | Subtab 
- 72 


DSU_Definition_Entry ! 
RGN 


REN 
Default_Hop_Count 


Logging 

GMT_Offset_Hours 

GMT_Offset_Minutes 

GMT_Offset_Direction 
Notes: 


1. The DSU_definition_entry parameter is supplied on Add_DSU_ Data, 
List DSU_Data, Modify_DSU_Data, and Remove_DSU_ Data. 


It is returned on List_DSU_Data. 


2. When DSU_definition_entry occurs as a child of row_se/ection_criteria or 
selected_row, any children of DSU_definition_entry may be used for selection, 
therefore nullifying the occurrences column. 


SUBTABLE: Intervention_List_Entry 


Table 58. Intervention_List_Entry 


Parameter Name Ref Length | Occurrences 
Page Num | Subtab 
Intervention_List_Entry | 509 | — 22 
RGN 541 1-8 _— 
REN | | 531 1-8 — 


Notes: 


1. The intervention_list_entry parameter is supplied on Add_DSU_ Data, 
List_DSU_Data, Modify_DSU_Data, and Remove_DSU_ Data. 


It is returned on List_DSU_Data. 


2. When intervention_list_entry occurs as a child of row_se/ection_criteria or 
selected_row, any children of intervention_fist_entry may be used for selection, 
therefore nullifying the occurrences column. 
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SUBTABLE: MU_ID_Registry_Entry 
Table 59. MU_ID_Registry_Entry 


Parm 


Parameter Name Ref Length | Occurrences 
Page poy Subtab 


MU_ID_Registry_Entry ' 
Net_ID 
LU_Name 
Mode_Name 
Direction 
MU_ID 
MU_ID_ State 
MU_Instance_Number 
Queue_Entry_ID 
Notes: 
1. 


a. The MU_/D_registry_entry parameter is supplied on Add_DSU_Data, 
List_DSU_Data, Modify _DSU_Data, and Remove_DSU_Data. 


It is returned on List_DSU_Data. 


b. The model of the protocol boundary assumes one MU_ID Registry for an entire 
DSU. 


2. When MU_ID_registry_entry occurs as a child of row_se/ection_criteria or 
selected_row, any children of MU_iD_registry_entry may be used for selection, 
therefore nullifying the occurrences column. 
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SUBTABLE: Next-DSU_Queue_Definitions_Entry 
Table 60. Next-DSU_Queue_Definitions_Entry 


Ref Length | Occurrences 


Parameter Name 


Next-DSU_Queue_Definitions_Entry |! 
Scheduling_Data 
Hold_State 
Net_ID 
LU_Name 
Mode_Name 


Notes: 
1. 


a. The next-DSU_queue_definitions_entry parameter is supplied on 
Add_DSU_Data, List_DSU_Data, Modify _DSU_Data, and Remove_DSU_Data. 


It is returned on List_DSU_ Data. 


b. The model of the protocol boundary assumes one next-DSU queue per con- 
nection. 


2. When next-DSU_queue_definitions_entry occurs as a child of row_se/ection_criteria 
or se/ected_row, any children of next-DSU_queue_definitions_entry may be used 
for selection, therefore nullifying the occurrences column. 
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SUBTABLE: Queue_ID 
Table 61. Queue_ID 


Parm 


Parameter Name Ref Length | Occurrences 
Page arene 


Queue_ID | 
Connection 
Net_ID 
LU_Name 

 Mode_Name 
Direction 

| Connection_Queue_Type | 

Dest_User 
Dest_DGN 
Dest_DEN 
Dest_Agent 


Note: 


1. The queue_identifier parameter is supplied, under various names, on several 
verbs. It is supplied on Get_Distribution_Info (queve_/D), Hold_Distribution_Copy 
(queue_/D), List_Queue_Entries (queuve_/D), Obtain _Local_Server_Report 
(distribution _queue_/D), Purge _Queue_Entry (queue_/D), and 
Release_Distribution Copy (queue_/D), Receive_Distribution 
(distribution_queue_/D), Receive_Distribution_Report (distribution _queue_!ID), and 
Receiving Sequence_Completed (distribution_queue_!D). 


It is returned on Get_Distribution_Log_ Entry (accessed_queue_!D), 
Get_Exception_Log Entry (accessed_queue_/D), and : 
List_Queues_ Containing Distribution (queue_/D). 


SUBTABLE: Report_Service_Parms 


Table 62. Report_Service_Parms 


Parm 


Parameter Name Ref | Length | Occurrences 
rage areas 


Report_Service_Parms ! 
Priority | 
Priority_Comp_Op | 
Protection 
Protection_Comp_Op | 
Security | 
Security_Comp_Op 


Note: 


1. The report_service_parameters parameter is supplied on Send_Distribution. 


It is returned on Get_Distribution_Info and Receive_Distribution. 
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SUBTABLE: Reported-On_Destination 


Table 63. Reported-On_Destination 


Parm 
Parameter Name Ref | Length | Occurrences 
fe i 


Reported-On_Destination |! 
Reported-On_Dest_DSU 
Reported-On_Dest_RGN 


Reported-On_Dest_REN 
Reported-On_Dest_User 
Reported-On_Dest_DGN 
Reported-On_Dest_DEN 
Note: 


1. The reported-on_destination parameter is returned on Get_Exception_Log_ Entry. 


It is also found in the SNA_condition_report subtable. 
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SUBTABLE: Routing_Table_Entry 
Table 64. Routing Table_Entry 


Parm 


Ref Length | Occurrences 
Page reer Subtab 


Parameter Name 


Routing_Table_Entry ! 
Dest_RGN 4 
Dest_REN 4 
Priority 
Priority_Comp_Op 
Protection 

Protection. Comp_Op 
Capacity 
Capacity_Comp_Op 
Security 

Security _Comp_Op 
Originating _Hop_Count 
Net_ID 
LU_Name 
Mode_Name 


Notes: 


1. The routing_table_entry parameter is supplied on Add_DSU_Data, List_DSU_Data, 
Modify_DSU_Data, and Remove_DSU_ Data. 


It is returned on List_DSU_Data. 


. When routing_table_entry occurs as a child of row_se/ection_criteria or 
selected_row, any children of routing _table_entry may be used for selection, there- 
fore nullifying the occurrences column. 


. The presence of each service parameter is dependent upon the presence of its 
corresponding comparison operator. 


. The dest_REN, or the dest_RGN and dest_REN may be specified with a system- 
specific value that matches any token for default routing. 
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SUBTABLE: Server_List_Entry 
Table 65. Server_List_Entry 


Parm 
Parameter Name Ref | Length ae ee 


Server_List_Entry ' 
Server 


Local_Info 
Restart_Capable 


Auxiliary_Operations 
Notes: 


1. The server_/ist_entry parameter is supplied on Add_DSU_ Data, List_DSU_Data, 
Modify DSU Data, and Remove_DSU_Data. 


It is returned on List_DSU_Data. 


2. When server_fist_entry occurs as a child of row_se/ection_criteria or selected_row, 
any children of server_/ist_entry may be used for selection, therefore nullifying the 
occurrences column. 


SUBTABLE: Service_Parms 


Table 66. Service_Parms 


Parm 
Parameter Name Ref | Length | Occurrences 
Page racy 


Service_Parms ! 
Priority 
Priority Comp_Op 
Protection 
Protection_Comp_Op 
Capacity 
Capacity_Comp_Op 
Security 
Security_Comp_Op 

Notes: 


1. The service_parameters parameter is supplied on List_Adjacent_DSUs, 
List_Connections, Reroute_Distribution_Copies, and Send_Distribution. 


It is returned on Get_Distribution_Info, Receive_Distribution, and 
Receive_Distribution_Report. 


. When service_parms are returned on Receive_Distribution_Report, capacity and 
Capacity_comp_op are not used. 


3. When used as selection criteria, a minimum of one service parameter/comparison 
operator combination may be specified. 
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SUBTABLE: SNA_Condition_Report 
Table 67. SNA_Condition_Report 


Parameter Name Ref Length | Occurrences 
= Fam | Subtab 
gas | 1.4 = 


SNA_Condition_Report ! 
SNA_Report_Code 
Structure_Report 

Structure_State 
Structure_Contents 
Parent_Spec 
Parent_ID_Or_T 
Parent_Class 
Parent_Position 
Parent_Instance 
Structure_Spec 
Structure_ID_Or_T 
Structure_Class 
Structure_Position 
Structure_Instance 
Structure_Segment_Num 
Structure_Byte_ Offset 
Sibling 
Reported-On_Destination 
Supplemental_Report 
Note: 


1. The SNA_condition_report parameter is returned on Receive_Distribution_Report. 
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SUBTABLE: Time 
Table 68. Time 


Parm 
Parameter Name Ref Length | Occurrences 
Page pr Subtab 


Time 1 
Hours 
Minutes 
Seconds 
Hundredths 
Local_Or_GMT_Fiag 


Note: 
1. A time is supplied, as after_time and before_time, on List_Queue_Entries. 


It is returned on Get_Distribution_Info (previous/y_received_time, 
distribution_time), Get_Distribution_Log Entry (/ogging_time), 
Get_Exception_Log Entry (/ogging_time), List_Distributions Being _Received 
(distribution_time), List_Distributions Being Sent (distribution_time), 
List_Queue_Entries (distribution_time, previously_received_time), 
Receive_Distribution (previous/y_received_time, distribution_time), 
Receive_Distribution_Report (report_time, previous/y_received_time, reported- 
on_time), and Send_Distribution (distribution_time). 


Parameter descriptions 


Accessed_Queue_ID 


Description: The accessed_queue_identifier is the queue containing the logged distribution, 
if any is applicable. 


Verbs Supplied on: None 
Verbs Returned on: Get_Distribution_Log Entry, Get_Exception_Log_Entry 


- Adjacent_DSU 


| Description: An adjacent_DSU is a DSU with which this DSU has an active connection ora 
DSU with which this DSU routinely establishes a connection. 


Verbs Supplied on: None 
Verbs Returned on: List_Adjacent_DSUs 
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Adjacent_REN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Adjacent_RGN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


-_After_Date 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Presence Rule: 


After_Time 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Presence Rule: 


The adjacent_REN is the second part of the name of the adjacent DSU. This is 
typically, but not necessarily, the LU name. 


None 
List_Adjacent_DSUs 


Character string 


CGCSGID: 


string Conventions: 


01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The adjacent_RGN is the first part of the name of the adjacent DSU. This is 
typically, but not necessarily, the network ID. 


None 
List_Adjacent_DSUs 


Character string 


CGCSGID: 


String Conventions: 


01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The after_date parameter, along with the after_time parameter, limits the 
selection of distributions to be listed to those that were originated after a 
certain date and time. 


List_Queue Entries 
None 


Occurs when after_time is present. 


The after_time parameter, along with the after_date parameter, limits the 
selection of distributions to be listed to those that were originated after a 
certain date and time. 


List_Queue_Entries 
None 


Occurs when after_date is present. 
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Agent 


Description: The agent is an application transaction program that interacts with DS on 
behalf of a user or a DSU. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: agent_list_entry, directory_entry 


Format: Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 
Agent_Correl 


Description: The agent_correlation is a string supplied by the origin agent. DS is not 
aware of its contents. 


Verbs Supplied on: Initiate_Read, Initiate_Write, Send_Distribution 
Verbs Returned on: Get_Distribution_Info, Receive_Distribution, Receive_Distribution_Report 


Format: Undefined byte string 


Agent_List_Entry 
Description: The agent_list_entry describes one row in the Agent List data structure. 
Verbs Supplied on: Add _DSU_Data, List_DSU_Data, Modify DSU_Data, Remove_DSU_Data 
Verbs Returned on: List_DSU_Data 
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Agent_Object 


Description: The agent_object is directly supplied by the origin agent. It is never parsed by 
the distribution service and is directly delivered, unchanged, to the agent at 
each destination. 


Verbs Supplied on: Initiate_Read, Initiate_Write, Send_Distribution 
Verbs Returned on: Get_Distribution_Info, Receive_Distribution, Receive_Distribution_Report 


Format: Undefined byte string 


Agent_Unit_Of_Work_ID 


Description: The agent_unit_of_work_identifier is an agent-defined byte string that the 
agent uses to identify a server unit of work. 


Verbs Supplied on: Assign _Read_Access, Initiate Read, Initiate Write, Release Read Access 
Verbs Returned on: None 


Format: Undefined byte string 


Assign_Unit_Of_Work_ID 


Description: The assign_unit_of_work_identifier flag indicates whether a new unit-of-work 
identifier is being assigned to a server unit of work. 


Verbs Supplied on: Assign _Read_Access 


Verbs Returned on: None 


Format: Enumeration 
Value Meaning 
YES A new unit of work is being used when assigning access 
to a process. 
NO The old unit of work is being used when assigning 
access to a process. 
Assigned_Process 
Description: The assigned_process is the process that is being assigned read access to a 


server object. 
Verbs Supplied on: Assign _Read_Access, Release Read Access 
Verbs Returned on: None 


Format: Character string, except for first byte 


490 _—s SNA//Distribution Services Reference 


CGCSGID: 


String Conventions: 


Assigning_Process 


01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


Description: The assigning_process is the process that is assigning read access to a server 
object, either to another process or to itself. 


Verbs Supplied on: Assign Read_Access, Release_Read_Access 


Verbs Returned on: None 


Format: Character string, except for first byte 


CGCSGID: 


String Conventions: 


Auxiliary_Operations 


01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


Description: The auxiliary_operations parameter indicates whether a specific server typi- 
cally uses direct fetch and direct store or whether it uses auxiliary operations. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: server_list_entry 


Format: Enumeration 
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Before_Date 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Presence Rule: 


Before_Time 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Presence Rule: 


Buffer 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Value Meaning 


This server always works by using direct fetch and 
direct store. This value is only allowed for servers at 
end-only role DSUs. 


DIRECT_OPERATIONS 


This server always does auxiliary operations to copy 
server objects to and from the general server. 


AUXILIARY_OPERATIONS 


EITHER This server is capable of doing either direct fetch and 


direct store or performing auxiliary operations to copy to 
and from the general server. 


The before_date parameter, along with the before_time parameter, limits the 
selection of distributions to be listed to those that were originated before a 
certain date and time. 


List_Queue_ Entries 
None 


Occurs when before_time is present. 


The before_date parameter, along with the before_time parameter, limits the 
selection of distributions to be listed to those that were originated before a 
certain date and time. 


List_ Queue_ Entries 
None 


Occurs when before_date is present. 


The buffer holds a portion of the server object to be read or written by a 
server. 


Read, Write 
None 
Undefined byte string 
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Buffer_Length 


Description: The buffer_length is the maximum amount of the server object a server can 
| write into a buffer. 


Verbs Supplied on: Read 


Verbs Returned on: None 


Format: Unsigned binary integer (1-origin); maximum: 2**64 - 2 
Capacity 
Description: The capacity service parameter indicates the capacity requirements for the 


distribution. The combination of this parameter and the 
capacity_comparison_operator yields the permitted levels of capacity for the 
distribution. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: routing_table_entry, service_parms 


Format: Enumeration 

Value Meaning 

ZERO No server object present 

1 MB Route through DSUs capable of handling at least 
1-megabyte server objects. 

4 MB Route through DSUs capable of handling at least 
4-megabyte server objects. 

16 MB Route through DSUs capable of handling at least 


16-megabyte server objects. 
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Capacity_Comp_Op 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Clean_Up_Date 
Description: 
Verbs Supplied on: 


Verbs Returned on: 


Clean_Up_Seqno 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


The capacity_comparison_operator parameter is used to allow a range of 
capacity service levels for a distribution. The combination of this parameter 
and the capacity parameter yields the permitted levels of capacity for the dis- 
tribution. 


None 
None 
routing tabie_entry, service_parms 


Enumeration 


Possible Values 


REQUIRE_LEVEL_GE 


The clean_up_date is the date portion of the sequence_number_to_clean_up. 
None 


Send_Distribution 


The clean_up_sequence_number is the sequence number portion of the 
Sequence_number_to_clean_up. 


None 
send_Distribution 


Signed binary integer (1-origin) 


Column_To_Be_Listed 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


A column_to_be_listed is one of the columns of a DSU data structure that 
should be returned on a List_DSU_Data verb. It is used to limit the display of 
a data structure to only those columns that are of interest to the issuer of the 
verb. 


List_DSU_Data 
None 


Enumeration 
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Value 


AGENT 
AUXILIARY_OPERATIONS 
CAPACITY 
CAPACITY_COMP_OP 
DATA_STREAM_FORMAT 
DAY 
DEFAULT_HOP_COUNT 
DEN 

DEST_REN 

DEST_RGN 

DGN 

DIRECTION 
GMT_OFFSET_DIRECTION 
GMT_OFFSET_HOURS 
GMT_OFFSET_MINUTES 
HOLD_STATE 

HOURS 

HUNDREDTHS 
LOCAL_INVOCATION_INFO 
LOCAL_OR_GMT_FLAG 
LOCAL_QUEUE_TYPE 
LOGGING 


LU_NAME 


MAX_DS_RECEIVES 
MAX_DS_SENDS 
MINUTES 


MODE_NAME 


MONTH 
MU_ID 
MU_ID_STATE 


MU_ID_INSTANCE_NUMBER 


Data Structure Found In 


Agent List and Directory 


Server List 

Routing Table 

Routing Table 
Connection Definitions 
Connection Definitions 
DSU Definition 
Directory 

Routing Table 

Routing Table 
Directory 


Connection Definitions and MU_ID Registry 


DSU Definition 
DSU Definition 
DSU Definition 


Next-DSU Queue Definitions 


Connection Definitions 


Connection Definitions 


Agent List, Directory, and Server List 


Connection Definitions 


Agent List and Directory 


DSU Definition 


Connection Definitions, MU_ID Registry, Next-DSU 


Queue Definitions, and Routing Table 


Connection Definitions 
Connection Definitions 


Connection Definitions 


Connection Definitions, MU_ID Registry, Next-DSU 


Queue Definitions, and Routing Table 


Connection Definitions 
MU_ID Registry 
MU_ID Registry 
MU_ID Registry 
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- Connection 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


NET_ID 


NEXT_SEQNO 
ORIGINATING_HOP_COUNT 
PRIORITY 
PRIORITY_COMP_OP 
PROTECTION 
PROTECTION_COMP_OP 
QUEUE_ENTRY_ID 

REN 
RESTART_CAPABLE 
RGN 
SCHEDULING_DATA 
SECONDS 

SECURITY 
SECURITY_COMP_OP 
SERVER 


YEAR 


Connection Definitions, MU_ID Registry, Next-DSU 
Queue Definitions, and Routing Table 


Directory 

Routing Table 

Routing Table 

Routing Table 

Routing Table 

Routing Table 

MU_ID Registry 

Directory, DSU Definition, and Intervention List 
Server List 

Directory, DSU Definition, and Intervention List 
Next-DSU Queue Definitions 

Connection Definitions 

Routing Table 

Routing Table 

Server List 


Connection Definitions 


A connection is a set of active or potential conversations between this DSU 
and an adjacent DSU using a given mode name. 


List_Connections, List_Conversations, List_Distributions_Being Received, 
List_Distributions Being Sent, Reroute_Distribution Copies, 
Reset_MU_ID_Registry, Start_Connection, Terminate_Connection 


List_Connections 


queue_!D 


Connection_Definitions_Entry 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


The connection_definitions_entry describes one row in the Connection Defi- 


nitions data structure. 


Add_DSU Data, List_DSU_Data, Modify_DSU_ Data, Remove _DSU_Data 


List_DSU_Data 
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Connection_Queue_Type 
Description: The connection_queue_type indicates the type of queue that is being selected. 
Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: queue_/D 


Format: Enumeration 


Possible Values 


NEXT-DSU 

CONTROL_MU 

MID_MU_RESTART 

ROUTER_DIRECTOR 
Control_Info 


Description: The control_information parameter provides the relevant information about an 
entry on a Control MU queue. 


Verbs Supplied on: None 


Verbs Returned on: List_Control_MU_ Queue 


Conversation_ID 


Description: The conversation_identifier is a system-specific method for identifying a spe- 
cific conversation. 


Verbs Supplied on: Terminate_Conversation 


Verbs Returned on: List_Conversations 


Format: Undefined byte string 
Conversation_Info 
Description: The conversation_information parameter contains the relevant information for 


a specific conversation. 
Verbs Supplied on: None 


Verbs Returned on: List_Conversations 
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Current_Unit_Of_Work_ID 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Data_Length 


Description: 


| Verbs Supplied on: 


Verbs Returned on: 


The current_unit_of_work_identifier gives the present unit_of_work_identifier. 
If a new_unit_of_work_identifier is also supplied on an Assign_Read_ Access 
verb, it replaces the current_unit_of_work_identifier. 


Assign_Read_Access 


None 


The data_length is the length of a portion of the server object found in the 
buffer. For a server reading an object into the buffer, it can be no longer than 
buffer_length. 


Write 
Read 


Format: Unsigned binary integer (1-origin); maximum: 2**64 - 2 
Data_Stream_Format 
Description: The data_stream_format flag indicates the type of data stream that should be 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Data_Structure 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


used on a specified connection. For more details, see Appendix D. 
None 

None 

connection_definitions_entry 


Enumeration 


Possible Values 


FORMAT_SET_1 
FORMAT_SET_2 
ERROR 


The data_structure is one of the DSU data structures that can be viewed and 
changed with the DS system-definition verbs. 


Add_DSU_Data, List_DSU_ Data, Modify_DSU_Data, Remove_DSU_Data 
None 


Enumeration 
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Possible Values 


AGENT_LIST 
CONNECTION_ DEFINITIONS 
DIRECTORY 
DSU_DEFINITION 
INTERVENTION LIST 
MU_ID_REGISTRY 
NEXT-DSU_QUEUE_DEFINITIONS 
ROUTING TABLE 
SERVER_LIST 
Day 
Description: The day parameter gives the day portion of the date. 
Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: connection_definitions_entry, date 


Format: Signed binary integer (1-origin) 


Default_Hop_Count 


Description: The default_hop_count is the hop count used on all distributions originated at 
this DSU, unless overridden by an originating_hop_count for a specific route 
segment in the routing table. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: DSU_definition_entry 


Format: Signed binary integer (1-origin) 
DEN 
Description: The DEN is the second part of the user name. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: directory_entry 


Format: Character string 
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CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 
String Conventions: 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 
Dest_Agent 


Description: The destination_agent is the transaction program at the destination DSU to 
which the distribution is to be delivered. 


Verbs Supplied on: Send_ Distribution 
Verbs Returned on: Get_Distribution_Info, Receive_Distribution 
Subtables Found in: queue_/D 


Format: Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 
byte. 
Dest_DEN 

Description: The destination_DEN is the second part of the name of a destination user. 

Verbs Supplied on: None 

Verbs Returned on: None 

Subtables Found in: destination, queue_ID 


Format: Character string 
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Dest_DGN 
Description: 
Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Dest_DSU 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Subtables Found in: 


CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 


String Conventions: 


Base 


ECS 


Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 


The destination_DGN is the first part of the name of a destination user. 


None 
None 
destination, queue_ID 


Character string 


CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 


String Conventions: 


Base 


ECS 


Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 


The destination_DSU is the name of one of the DSUs to which the distribution 


is to be sent. 
List_Connections 
None 


destination 
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Dest_REN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Dest_RGN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Dest_User 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


The destination_REN is the second part of a destination DSU name. This is 
typically, but not necessarily, the LU name. : 


List_Connections 
None 
destination, routing_table_entry 


Character string 


CGCSGID: 


String Conventions: 


01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The destination_RGN is the first part of a destination DSU name. This is typi- 
cally, but not necessarily, the network ID. 


List_Connections 
None 
destination, routing_table_entry 


Character string 


CGCSGID: 


String Conventions: 


01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The destination_user is the name of one of the users to which the distribution 
is to be sent. 


None 
None 


destination, queue_ID 
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Destination 
Description: 
Verbs Supplied on: 
Verbs Returned on: 
Note: 


DGN 
Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Direction 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The destination is one of the intended recipients of a distribution. 


Send_Distribution 


Get_Distribution_Info, Get_Distribution_Log Entry, Receive Distribution 


For Send_Distribution, either dest_DSU or dest_user is specified. For 


Get_Distribution_Info, Get_Distribution Log Entry, and Receive_Distribution, 


dest_DSU is always present and dest_user is optional. 


The DGN is the first part of the user name. 


None 
None 
directory_entry 


Character string 


CGCSGIDs: 


String Conventions: 


01134-00500 (Base), 00930-00500 (Enhanced Char Set) 


Base 


ECS 


Leading, imbedded, and trailing space (X’40’) 


characters are not allowed. 


Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 


characters are significant. 


The direction flag tells whether a particular conversation or connection is 
being used for sending or receiving. 


List_Control_ MU_Queue 
Get_Distribution_Log Entry, Get_Exception_Log Entry, List_Conversations 


connection_definitions_entry, MU_ID_registry_entry, queue_ID 


Enumeration 
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Directory_Entry 
Description: 
Verbs Supplied on: 


Verbs Returned on: 


Distribution_ID 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Distribution_Info 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Value Meaning 


SENDING This conversation or connection is being used by 
DS_Send for sending MUs. 


RECEIVING This conversation or connection is being used by 
DS_ Receive for receiving MUs. 


The directory_entry describes one row in the Directory data structure. 
Add_DSU_ Data, List_DSU_Data, Modify DSU Data, Remove_DSU_Data 
List_DSU_Data 


The distribution_identification is the unique identifier for a distribution. It is 
assigned at the origin DSU, and is used for all references to that distribution 
as it moves through the network. The distribution_identification applies to all 
copies of the distribution that may be generated by fan-out, and to any reports 
that are generated during the progress of the distribution. 


Assign Read Access, Get_Distribution_Log Entry, Get_Exception_Log Entry, 
Initiate_Read, Initiate_Write, List_Queue_Entries, 

List_Queues Containing Distribution, Query_Distribution Sending, 
Receive_Distribution, Receive_Distribution Report, Release _Read_Access, 
Reroute_Distribution Copies, Send_Distribution, 

Sending Sequence_Completed 


Get_Distribution_Info, Get_Distribution_Log Entry, Get_Exception_Log Entry, 
List_Distributions Being Received, List_Distributions Being Sent, 
List_Queue_ Entries, Receive _Distribution, Receive _Distribution_Report 


The distribution_information parameter provides the relevant information on a 
distribution. 


None 


List_Distributions Being Sent, List_Distributions Being Received, 
List_Queue_ Entries : 
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Distribution_Log_ Data 


Description: The distribution_log data contains the data that was logged with a distrib- 
ution. 


Verbs Supplied on: None 
Verbs Returned on: Get_Distribution_Log Entry 
Format: Product defined byte string 


Distribution_Queue_!ID 


Description: The distribution_queue_identifier is the name of a local delivery queue. It is 
either a user name or an agent name. 


Verbs Supplied on: Obtain_Local_Server_Report, Receive_Distribution, 
Receive_Distribution Report, Receiving Sequence Completed 


Verbs Returned on: None 


Distribution_Time 
Description: The distribution_time is the time at which the distribution originated. 
Verbs Supplied on: None 


Verbs Returned on: Get_Distribution_Info, List_Distributions Being Received, 
List_Distributions Being Sent, List_Queue_Entries, Receive_Distribution, 
Send_Distribution 


DSU_Definition_Entry 
Description: The DSU _definition_entry describes the fields in the DSU Definition data struc- 
ture. 


Verbs Supplied on: Add _DSU_Data, List DSU Data, Modify DSU Data, Remove DSU _ Data 
Verbs Returned on: List_DSU_Data 
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Exception_Log_Data 


Description: The exception_log_data contains the data that was logged for an exception. 
Verbs Supplied on: None 
Verbs Returned on: Get_Exception_Log Entry 


Format: Undefined byte string 


Exception_Report_Req 


Description: The exception_report_requested parameter indicates whether or not exception 
reports were requested on a distribution. 


Verbs Supplied on: Send_Distribution 


Verbs Returned on: Get_Distribution_Info, Receive _Distribution | 


Format: Enumeration 
Value Meaning 
YES Exception reporting is requested. This value is allowed © 
only for high-integrity distributions. 
NO Exception reporting is not requested. 


GMT_Offset_Direction 


Description: The GMT_offset_direction parameter indicates whether a DSU’s local time is 
earlier or later than GMT. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: DSU _definition_entry 


Format: Enumeration 
Value Meaning 
EARLIER Local time is earlier than GMT. 


LATER Local time is Jater than GMT. 
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GMT_Offset_Hours 


Description: 

Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


The GMT_offset_hours is the hours portion of the local DSU’s offset from GMT. 
None 

None 

DSU_definition_entry 

Signed binary integer (1-origin) 


GMT_Offset_Minutes 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Hold_State 


Description: 


Verbs Supplied on: 


| Verbs Returned on: 


Subtables Found in: 


Format: 


The GMT_offset_minutes is the minutes portion of the local DSU’s offset from 
GMT. 


None 

None 

DSU _definition_entry 

Signed binary integer (1-origin) 


The hold_state indicates whether a hold has been put on a next-DSU queue, 
and if so, whether the hold was generated in response to an exception or gen- 
erated by an operator. 


None 
List_Connections, List_Queue_Entries 
next-DSU_queue_definitions_entry 


Enumeration 


Value Meaning 
NOT_HELD | No hold has been placed on this queue. 
EXCEPTION_HELD A hold has been placed on this queue by the DSU as the 


result of an exception. 


OPERATOR_HELD A hold has been placed on this queue by the operator. 
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Hop_Count 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


Hours 
Description: 
Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Hundredths 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


The hop count is the remaining number of hops that may be traversed by a 


DS distribution on its way toward its destination DSU(s). The hop count is set 
by the origin DSU for a distribution and by the reporting DSU for a distribution 
report. The hop count is decremented by 1 in every DSU through which the 
distribution passes. If the hop count reaches 0 at an intermediate DSU, 
exception processing is invoked. 


None 
Get_Distribution_Info 


Signed binary integer (1-origin); maximum: 32,767 


The hours parameter gives the hours portion of the time. 
None 

None 

connection_definitions_entry, time 


Signed binary integer (1-origin) 


The hundredths parameter gives the hundredths-of-a-second portion of the 
time. 


None 
None 


connection_definitions_entry, time 


Format: Signed binary integer (1-origin) 
if_ Nonunique_Key 
Description: The if_nonunique_key flag instructs the DSU on how to proceed if a request to 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


change a DSU data structure finds more than one row that match the key 
given on the request. 


Modify _DSU_Data, Remove_DSU_Data 
None 


Enumeration 
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Integrity 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


Value 


MODIFY_ALL 


MODIFY_FIRST 


MODIFY_AND_REMOVE 


MODIFY_NONE 
REMOVE_ALL 
REMOVE_FIRST 


REMOVE_NONE 


Meaning 


Modify all existing rows that match the key to have the 
new row values. 


Modify only the first matching row to have the new row 
values. 


Modify the first matching row to have the new row 
values; remove all other matching rows. 


Do not modify any rows. 
Remove all existing rows that match the key. 
Remove the first matching row. 


Do not remove any rows. 


The integrity flag indicates whether DS should use confirmation protocols on 
the conversation and at the PB to prevent losses or duplications of this distrib- 
ution. For more details, see Chapter 2. 


Send_Distribution 


Get_Distribution_Info, Receive_Distribution, Receive Distribution Report 


Enumeration 


Value 


HIGH 


BASIC 


Intervention_List_Entry 


Description: 


Meaning 


The sending agent uses Sending Sequence_Completed 
to manage the transfer of the distribution from the agent 
to the DSU. Also, the DSU uses confirmation flows and 
MU_IDs when sending the distribution from one hop to 
the next. 


All responsibility for preventing losses and duplicates of 
the distribution rests with the agent. The distribution 
service makes no extra effort to guard against losses 
and duplicates during transmission of the distribution. 
Exception reporting can not be requested for a basic- 
integrity distribution. 


The intervention_list_entry describes one row in the Intervention List data 


structure. 


Verbs Supplied on: Add_DSU_Data, List_DSU_Data, Modify DSU_Data, Remove_DSU_Data 


Verbs Returned on: 


List_ DSU_Data 
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| Last_Byte_Received 


Description: The last_byte_received is the last byte received by the receiving DSU before 
the MU was suspended. The byte count begins with the first byte of atomic 
data within the encompassing structure. A byte count of X’FFFFFFFFFFFFFFFF’ 
indicates that the structure was fully received. The byte count contains only 
atomic data and does not contain the segmenting LLs for segmented struc- 
tures. 


Verbs Supplied on: None 
Verbs Returned on: Query_Last_Byte_Received 


Format: Unsigned binary integer (1-origin) 
Local_Info : 
Description: The focal_info is the information that is kept for a local program, such as an 


agent or server. This could be a module name, default parameters, or any 
other required system-specific information. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: agent_list_entry, directory_entry, server_list_entry 


Format: Undefined byte string 
Local_Or_GMT_Flag 
Description: The local_or_GMT_flag tells how a time value that passes across the protocol 


boundary should be interpreted. 
Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: connection_definitions_entry, time 


Format: | Enumeration © 
Value Meaning 
LOCAL The time is the local time value for this DSU. 
GMT _ The time is a GMT time value. 
ORIGIN_LOCAL | The time is the local time value at the origin DSU of the 


distribution. 
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Local_Queue_Type 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Logging 
Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


- Logging_Date 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


The local_queue_type is the type of queue that is used to deliver distributions 
to a specific user by a specific agent. 


None 
None 
agent _list_entry, directory_entry 


Enumeration 


Value Meaning 
AGENT The queue is identified by the agent name. 
USER The queue is identified by the user name. 


The logging flag specifies whether or not the DSU is currently doing optional 
distribution logging. 


None 


None 


DSU_definition_entry 


Enumeration. 
Value 
YES Perform optional distribution logging. 


NO Do not perform optional distribution logging. 


The logging_date, along with the logging_time, specifies the date and time a 
log entry was generated. 


None | 


Get_Distribution_Log_Entry, Get_Exception_Log_Entry 
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Logging_Time 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


LU_ Name 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Max_DS_Receives 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Presence Rule: 


Format: 


The logging_time, along with the logging_date, opera es the date and time a 
log entry was generated. 


None 


Get_Distribution Log Entry, Get_Exception_Log_ Entry 


The logical_unit_name is the second part of a network-qualified LU-name. It is 
usually, though not always, the same as the REN. 


Initiate_Read, Initiate Write, List_Connections, List_Control_MU_Queue, 
List_Conversations, List_Distributions Being Received, 
List_Distributions Being Sent, Query_Last_Byte_Received, 
Reroute_Distribution Copies, Reset_MU_ID_Registry, Start_Connection, 
Terminate_Connection, Terminate_Restartability 


Get_Distribution_Log Entry, Get_Exception_Log Entry, List_Connections, 
List_Conversations 


connection_definitions_entry, MU_ID_registry_entry, 
next-DSU_queue_definitions_entry, queue_ID, routing_table_entry 


Character string 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The maxinum_DS_ Receives is the largest number of instances of DS_Receive 
that can be active on a connection. 


Start_Connection 
None 
connection_definitions_entry 


Occurs when the value of direction is RECEIVING. 


Signed binary integer (1-origin) 
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Max_DS_Sends 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Presence Rule: 


Format: 


Minutes 
Description: 


| Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Mode_Name 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The maximum_DS_Sends is the largest number of instances of DS_Send that 
can be active on a connection. It should typically be less than or equal to the 
number of conwinner sessions the DSU has for that connection. 


Start_Connection 

None 

connection_definitions_eniry 

Occurs when the value of direction is SENDING. 


Signed binary integer (1-origin) 


The minutes parameter gives the minutes portion of the time. 
None 

None 

connection _definitions_entry, time 


Signed binary integer (1-origin) 


The mode_name identifies the type of traffic that is appropriate for a specific 
conversation. 


Initiate_Read, Initiate_Write, List_Connections, List_Control_MU_ Queue, 
List_Conversations, List_Distributions Being Received, 
List_Distributions Being Sent, Query_Last_Byte_Received, 
Reroute_Distribution_Copies, Reset_MU_ID_Registry, Start_Connection, 
Terminate_Connection, Terminate_Restartability 


Get_Distribution_Log Entry, Get_Exception_Log Entry, List_Connections, 
List_Conversations 


connection_definitions_entry, MU_ID_registry_entry, 
next-DSU_queue_definitions_entry, queue_ID, routing_tabie_entry 


Undefined byte string 


913 
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Modified_Row 
Description: A modified_row replaces one or more rows specified by row_selection_criteria 
on a Modify. DSU_Data verb. 
Verbs Supplied on: Modify_DSU_Data 


Verbs Returned on: None 


Month 
Description: The month parameter gives the month portion of the date. 
Verbs Supplied on: None | 
Verbs Returned on: None 


Subtables Found in: connection_definitions_entry, date 


Format: Signed binary integer (1-origin) 
MU_Action 
Description: The message_unit_action flag indicates what action should be taken on distrib- 


utions that are currently being sent or received on a conversation (or con- 
nection) that is being terminated. | | 


Verbs Supplied on: Terminate_Connection, Terminate_Conversation 


Verbs Returned on: None 


Format: Enumeration 

Value Meaning 

ABORT Abort all distributions being sent or received on the con- 
versation or connection. 

COMPLETE Complete any distributions currently being sent or 
received on the conversation or connection, but do not 
begin any new distributions. 

SUSPEND Suspend any distributions currently being sent or 
received on the conversation or connection for later 
restart. 
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MU_ID 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The message_unit_identifier is a number that uniquely identifies a distribution 
MU throughout its existence. An MU exists for only one hop, from one DSU to 
the adjacent DSU. An MU_ID is unique only for a particular LU name, mode 
name combination. 


Initiate_Read, Initiate_Write, Query_Last_Byte_Received, 
Terminate_Restartability 


Get_Distribution_Info, Get_Distribution_Log Entry, Get_Exception_Log Entry, 
List_Control MU_Queue 


MU_ID_registry_entry 
Signed binary integer (1-origin) 


MU_ID_Registry_Entry 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


MU_ID_ State 


Description: 


| Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


The MU_ID_registry_entry describes one row in the MU_ID Registry data 
structure. 


Add_DSU_Data, List_DSU_Data, Modify_DSU_Data, Remove_DSU_Data 
List_DSU_ Data 


The message_unit_identifier_state indicates the state of processing, on either 
the send or receive side, for an MU_ID. For details of the meaning of each 
state, see Chapter 2. 


None 
None 
MU_ID_registry_entry 


Enumeration 


Value Send or Receive Side Occurrence 
COMPLETED Receive side 

CQMU_PENDING Send side 

IN_ TRANSIT Both send and receive sides 
NOT_ASSIGNED Send side 

NOT_RECEIVED Receive side 

PURGED Both send and receive sides 
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RETRY_PENDING Send side 

SUSPENDED Both send and receive sides 
TERMINATED Receive side 

TERMINATION PENDING Send side 


TRANSFER_PENDING Send side 


MU_Instance_Number 


Description: The message_unit_instance_number identifies the instance of a particular dis- 
tribution message unit and its corresponding MU_ID. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: MU_ID_registry_entry 


Format: Signed binary integer (1-origin) 
MU_Type 
Description: The MU_type indicates the type of MU that is found on a Control MU queue. 


Verbs Supplied on: None 


Verbs Returned on: List_Control_MU_Queue 


Format: Enumeration 
Value Meaning 
SEMU Sender-Exception Message Unit 
REMU Receiver-Exception Message Unit 
CQMU Completion-Query Message Unit 
CRMU Completion-Report Message Unit 
PRMU Purge-Report Message Unit 
RRMU Reset-Request Message Unit 
RAMU Reset-Accepted Message Unit 
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Net_ID 


Description: 


Verbs Supplied on: 


Verbs Returned on: 
Subtables Found in: 


Format: 


New_Row 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


The network_identifier is the first part of a network-qualified LU-name. It is 
usually, though not always, the same as the RGN. 


Initiate_Read, Initiate_Write, List_Connections, List_Control_ MU Queue, 
List_Conversations, List_Distributions Being Received, 
List_Distributions Being Sent, Query_Last_Byte_ Received, 
Reroute_Distribution Copies, Reset_MU_ID Registry, Start_Connection, 
Terminate Connection, Terminate_Restartability 


Get_Distribution_Log Entry, Get_Exception_Log Entry, List_Connections, 
List_Conversations 


connection_definitions_entry, MU_ID_registry_entry, 
next-DSU_queue_definitions_entry, queue_ID, routing table_entry 


Character string 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


A new_row is a row being added to a DSU data structure by the 
Add_DSU_Data verb. 


Add_DSU_Data 


None 


New_Row_Number 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


The new_row_number is the next row that matches the row_selection_criteria 
specified on a List_DSU_ Data verb. It is used when there are too many 
matching rows to return on one invocation of the List_DSU_Data verb. To 
obtain further information, the agent reissues List_DSU_Data, using the value 
returned in new_row_number as the starting_row_number. 


None 
List_DSU_Data 
Signed binary integer (1-origin) 
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New_Unit_Of_Work_ID 


Description: The new_unit_of_work_identifier provides the value that should replace the 
current_unit_of_work_identifier. 


Verbs Supplied on: Assign _Read_ Access 


Verbs Returned on: None 


Next-DSU_Queue_Definitions_Entry 


Description: The next-DSU_queue_definitions_entry describes one row in the Next-DSU 
Queue Definitions data structure. 


Verbs Supplied on: Add _DSU_Data, List_DSU_Data, Modify DSU Data, Remove_DSU_Data 
Verbs Returned on: List_DSU_Data 


Next_MU_ID 


Description: The next_message_unit_identifier indicates which MU_ID should be expected 
next when the two MU_ID registries for a connection are synchronized. 


Verbs Supplied on: Reset_MU_!ID_ Registry 


Verbs Returned on: None 


Format: Signed binary integer (1-origin) 
Next_Queue_Entry_ID 
Description: The next_queue_entry_identifier indicates the next queue_entry_identifier to be 


listed on a List_Queue_Entries verb. It occurs when there were too many dis- 
tributions to be listed on one invocation of the List_Queue_Entries verb. 


Verbs Supplied on: None 
Verbs Returned on: List_Control_MU_Queue, List_Queue_ Entries 


Format: Undefined byte string 
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Next_Seqno 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


The next_sequence_number is the sequence number to be used on the next 
distribution sent on this date for a specific user by a specific agent. The 
sequence number is reset to 1 for the first distribution each day. 


None 

None 

directory_entry 

Signed binary integer (1-origin) 


Number_Of_Matching_Entries 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


Origin_Agent 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


The number_of_matching_entries indicates how many log entries match the 
given distribution identification. 


None 
Get_Distribution_Log Entry, Get_Exception_Log Entry 
Signed binary integer (1-origin) 


The origin_agent is the transaction program at the origin DSU that originated 
the distribution. 


None 
None 
distribution_ID 


Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 
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Origin_Date 
Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Origin_DEN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Origin_DGN 
Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The origin_date is the date on which the distribution originated. 


None 
None 


distribution_ID 


The origin_DEN is the second part of the user name of the distribution origi- 


nator. 
None 
None 
distribution_ID 


Character string 


CGCSGIDs: 


String Conventions: 


01134-00500 (Base), 00930-00500 (Enhanced Char Set) 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 
ECS Leading space (X’40’) characters are disal- 


lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 


The origin _DGN is the first part of the user name of the distribution originator. 


None 
None 
distribution_ID 


Character string 
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Origin_DSU 
Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Origin_REN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Origin_RGN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 


String Conventions: 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 
ECS Leading space (X’40’) characters are disal- 


lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 


The origin_DSU is the name of the DSU at which the distribution originated. 
None 
None 


distribution_ID 


The origin_REN is the second part of the name of the DSU at which the distrib- 
ution originated. This is typically, but not necessarily, the LU name. 


None 

None 
distribution_ID 
Character string 
CGCSGID: 01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


String Conventions: 


The origin _RGN is the first part of the name of the DSU at which the distrib- 
ution originated. This is typically, but not necessarily, the network ID. 


None 
None 
distribution_ID 


Character string 
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CGCSGID: 01134-00500 (Character Set AR) 
String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 
Origin_Seqno 


Description: The origin_sequence_number is the number assigned to the distribution by the 
origin agent as part of the distribution_identification. For FS2, the number 
ranges from 1 to (2**31)-1. For FS1, the number ranges from 0 (for report 
MUs) to 9999. Refer to Appendix D for migration details. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: distribution_ID 


Format: | Signed binary integer (1-origin) 


Origin_User 
Description: The origin_user is the user name of the originator of the distribution. 
Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: distribution_ID 


Originating Hop_Count 


Description: The originating _hop_count specifies the hop count to be used for distributions 
on a particular route segment. It overrides the defau/lt_hop_count for the DSU. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: routing_table_entry 


Format: Signed binary integer (1-origin) 
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Parent_Class 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Parent_ID_Or_T 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Parent_Instance 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The parent_class is the class of a parent structure. For more details on the 


classes of structures, see Appendix G. 
None 

None 

SNA_condition_report 


Enumeration 


Possible Values 


LENGTH BOUNDED LLID 
LENGTH BOUNDED LT 
DELIMITED_LLID 
DELIMITED_LT 
IMPLIED_LLID 
IMPLIED_LT 


The parent_ID_or_T is the ID or T value of a parent structure. ID’s are the 
registered GDS codepoints and are referred to in SNA Formats. T’s are 
architecture-specific values relative to the encompassing ID. 


None 
None 
SNA_condition_report 
Undefined byte string 


The parent_instance is used when a parent structure occurs multiple times. 
The value of parent_instance identifies the particular instance within a posi- 
tion. | 


None 

None 

SNA_condition_report 

Signed binary integer (1-origin) 
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Parent_Position 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Parent_Spec 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


The parent_position is the position of this parent structure within its parent (if 
one exists) in this particular MU. Multiple consecutive instances of a repeat- 
able parent structure share a single position; they can be distinguished by 
parent_instance. 


None 

None 

SNA_condition_report 

Signed binary integer (1-origin) 


The parent_specification contains the identifier (ID or T) and the class of a 
parent structure. For a parent structure that occurs multiple times, the 
instance may also be included. The value of the parent_instance identifies the 
particular instance. The position of this parent structure within its parent (if 
one exists) may also be included. This would typically be done when this 
parent structure is an unordered child of its parent. 


None 
None 


SNA_condition_report 


Previously_Received_Date 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


The previously_received_date is the date portion of the 
previously_received_date_time. 


None 


Get_Distribution_Info, List_Queue_Entries, Receive_Distribution, 
Receive_Distribution_Report 
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Previously_Received_Date_Time 


Description: The previously_received_date_time indicates when this distribution or report 
had been earlier received. The previous receive verb was never acknowl- 
edged with a Receiving Sequence Completed verb, and the DSU is now trying 
to account for this failure to acknowledge receipt of the distribution or report. 


Verbs Supplied on: None 


Verbs Returned on: Get_Distribution_Info, List_Queue_ Entries, Receive Distribution, 
Receive_Distribution_Report 


Previously_Received_Time 


Description: The previously_received_time is the time portion of the 
previously_received_date_time. 


Verbs Supplied on: None 


Verbs Returned on: Get_Distribution_Info, List_Queue_Entries, Receive_Distribution, 
Receive_Distribution Report 


Priority 


Description: The priority service parameter indicates the priority requirements for the dis- 
tribution. The combination of this parameter and the 
' priority_comparison_operator yields the permitted levels of priority for the dis- 
tribution. 


Verbs Supplied on: None 

Verbs Returned on: None 

Subtables Found in: report_service_parms, routing_table_entry, service_parms 
| Format: Enumeration 


Note: For the Folding Data Priorities elective, DATAH! replaces DATA_9 through 
DATA_16 and DATALO replaces DATA_1 through DATA_8. 
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Possible Values 


FAST 
CONTROL 
DATA_16 
DATA_15 
DATA_14 
DATA_13 
DATA_12 
DATA_11 
DATA_10 
DATA_9 
DATA_8 
DATA_7 
DATA_6 
DATA_5 
DATA_4 
DATA_3 
DATA_2 
DATA_1 


Priority_Comp_Op 


Description: The priority_comparison_operator parameter is used to allow a range of pri- 
7 ority service levels for a distribution. The combination of this parameter and 
the priority parameter yields the permitted levels of priority for the distrib- 
ution. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: report_service_parms, routing_table_entry, service_parms 


Format: Enumeration 


Possible Values 


REQUIRE_LEVEL_GE 


Product_Specific_Data 


Description: The product_specific_data specifies product data that is associated with the 
distribution, or which could be helpful in problem determination. 


Verbs Supplied on: None 
Verbs Returned on: Get_Distribution_Log Entry, Get_Exception_Log Entry 
Format: Undefined byte string 


526 SNA/Distribution Services Reference 


Program_Name 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


Protection 


Description: 


| Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The program_name specifies the name of the program that generated the log 
entry. 


None 
Get_Distribution_Log Entry, Get_Exception_Log_ Entry 


Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


The protection service parameter indicates the protection requirements for the 
distribution. The combination of this parameter and the 
protection_comparison_operator yields the permitted levels of protection for 
the distribution. 


None 
None 
report_service_parms, routing_table_entry, service_parms 


Enumeration 


Value Meaning 
LEVEL‘ _ Safe store is not performed. 
LEVEL2 Safe store must be performed. 


Protection_Comp_Op 


| Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The protection_comparison_operator parameter is used to allow a range of 
protection service levels for a distribution. The combination of this parameter 
and the protection parameter yields the permitted levels of protection for the 
distribution. 


None 
None 
report_service_parms, routing table_entry, service_parms 


Enumeration 
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Possible Values 
REQUIRE_LEVEL_GE 


Querying_Agent 


Description: The querying_agent is the agent that issues a List_Queue Entries verb. It 
might not be the same agent that originated the distribution. 


Verbs Supplied on: List_Queue_Entries 
Verbs Returned on: None 


Format: Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 
byte. 

Queue_Entry_!ID 


Description: The queue_entry_identifier specifies one particular entry in a given queue. 
The combination of queue_identifier and queue_entry_identifier uniquely iden- 
tify any distribution copy in the DSU. 


Verbs Supplied on: Get_Distribution_Info, Hold Distribution _Copy, Obtain _Local_Server_Report, 
Purge Queue Entry, Receive_Distribution, Receive_Distribution_Report, 
Receiving Sequence_Completed, Release_Distribution_Copy 


Verbs Returned on: List_Control MU Queue, List_Queue_Entries, Obtain _Local_Server_Report, 
Receive_Distribution, Receive _Distribution_Report 


Subtables Found in: MU_ID_registry_entry 
Format: Undefined byte string 


Queue_Entry_Type 
Description: The queue_entry_type specifies what is found in a given queue entry. 
Verbs Supplied on: List_Queue_ Entries | 
Verbs Returned on: List_Queue_Entries 


Format: Enumeration 
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Possible Values 


DISTRIBUTION 

DISTRIBUTION_REPORT 

SERVER_REPORT 
Queue_ID 


Description: The queue_identifier specifies one particular local delivery queue or next-DSU 
queue. The combination of queve_identifier and queue_entry_identifier 
uniquely identify any distribution copy in the DSU. 


Verbs Supplied on: Get_Distribution_Info, Hold_Distribution Copy, List_Queue_ Entries, 
Purge Queue Entry, Release Distribution Copy 


Verbs Returned on: List_Queues Containing Distribution 


Received_Server_Bytes 


Description: The received_server_bytes parameter indicates how many bytes of the server 
object have been received. This parameter is applicable only to a distribution 
currently being received at this DSU. 


Verbs Supplied on: None 


Verbs Returned on: List_Distributions Being Received 


Format: Unsigned binary integer (1-origin); maximum: 2**64 - 2 
Receiving_Agent 
Description: The receiving_agent is the agent that receives a distribution, distribution 


report, or server report. 


Verbs Supplied on: Obtain_Local_ Server_Report, Receive_Distribution, 
Receive_Distribution_Report 


Verbs Returned on: None 


Format: Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 
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Receiving_DSU 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Receiving_REN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Receiving RGN 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


The receiving_DSU is the name of the DSU that was receiving a distribution 
about which a report is being generated. 


None 


Receive_Distribution_Report 


The receiving_REN is the second part of the name of the DSU that was 
receiving a distribution about which a report is being generated. This is typi- 
cally, but not necessarily, the LU name. 


None 

Receive_Distribution_Report 
Character string 
CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 


are not allowed. 


The receiving_RGN is the first part of the name of the DSU that was receiving 
a distribution about which a report is being generated. This is typically, but 
not necessarily, the network ID. 


None 

Receive_Distribution_Report 
Character string 
CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 


are not allowed. 


Remaining_Server_Bytes 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 
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The remaining_server_bytes parameter indicates how many bytes of the 
server object remain to be sent. This parameter is applicable only to a dis- 
tribution currently being sent by this DSU. 


None 
List_Distributions Being Sent 


Unsigned binary integer (1-origin); maximum: 2**64 - 2 


REN 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Report-To_Agent 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


Report-To_DEN 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


The REN is the second part of the DSU name. This is typically, but not neces- 
sarily, the LU name. 


None 
None 
directory_entry, DSU_definition_entry, intervention_list_entry 


Character string 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The report-to_agent is the name of the application transaction program to be 
started after the report is queued for delivery. 


Send_Distribution 
Get_Distribution_Info, Receive_Distribution, Receive_Distribution_Report 


Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


The report_to_DEN is the second part of the user name to which distribution 
reports are to be sent. 


Send_Distribution 
Get_Distribution_Info, Receive_Distribution, Receive_Distribution_Report 


Character string 
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CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 
String Conventions: 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space {X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 
Report-To_DGN 


Description: The report_to_DGN is the first part of the user name to which distribution 
reports are to be sent. 


Verbs Supplied on: Send_Distribution 
Verbs Returned on: Get_Distribution_Info, Receive _Distribution, Receive Distribution Report 


Format: Character string 


CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 
String Conventions: 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 
Report-To_DSU 


Description: The report-to_DSU is the name of the DSU to which distribution reports are to 
be sent. 


Verbs Supplied on: Send_Distribution 


Verbs Returned on: Get_Distribution_Info, Receive Distribution, Receive Distribution Report 


Report-To_REN 


Description: The report-to_REN is the second part of the DSU name to which distribution 
reports are to be sent. This is typically, but not necessarily, the LU name. 


Verbs Supplied on: Send_Distribution 
Verbs Returned on: Get_Distribution_Info, Receive_Distribution, Receive _Distribution_Report 


Format: Character string 
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Report-To_RGN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Report-To_User 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Report_Date 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


CGCSGID: 01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


String Conventions: 


The report-to_RGN is the first part of the DSU name to which distribution 
reports are to be sent. This is typically, but not necessarily, the network ID. 


send_Distribution 
Get_Distribution_Info, Receive Distribution, Receive Distribution Report 


Character string 


CGCSGID: 01134-00500 (Character Set AR) 


Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


String Conventions: 


The report-to_user is the name of the user to which distribution reports are to 
be sent. 


Send_Distribution 


Get_Distribution_Info, Receive Distribution, Receive Distribution _Report 


The report_date contains the date on which the reporting DSU generated the 
report. 


None 


Receive_Distribution_Report 
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Report_Service_Parms 


Description: The report_service_parameters describe the service requested for the distrib- 
ution report by the origin agent when the agent wants to override the service 
parameters that would be routinely generated by the reporting DSU for the 
report MU. If report service parameters are specified, they are used as the 
service parameters in any DRMUs that are generated as part of the distrib- 
ution. If the origin agent does not provide report service parameters, a DSU 
that generates a report derives service parameters for the DRMU from the 
service parameters in the DTMU. 


Verbs Supplied on: Send_Distribution 


Verbs Returned on: Get_Distribution_Info, Receive_Distribution 


Report_Time 


Description: The report_time contains the time at which the reporting DSU generated the 
report. 


Verbs Supplied on: None 


Verbs Returned on: Receive_Distribution_Report 


Reported-On_Dest_Agent 


Description: The reported-on_destination_agent is the name of the intended destination 
agent of the distribution that is being reported on. 


Verbs Supplied on: None 


Verbs Returned on: Receive_Distribution_Report 


Presence Rule: Occurs when dest_agent was specified in the reported-on distribution. 
Format: Character string, except for first byte 
CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 

program is not SNA registered. X’40’ is not a valid first 

byte. 
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Reported-On_Dest_DEN 


Description: The reported-on_destination_DEN is the second part of the name of one of the 
original destination users being reported on. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: reported_on_destination 


Format: Character string 


CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 
String Conventions: 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 
Reported-On_Dest_DGN 


Description: The reported-on_destination_DGN is the first part of the name of one of the 
original destination users being reported on. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: reported_on_destination 


Format: Character string 


CGCSGIDs: 01134-00500 (Base), 00930-00500 (Enhanced Char Set) 
String Conventions: 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are disal- 
lowed, trailing space (X’40’) characters are 
not significant, and imbedded space (X’40’) 
characters are significant. 
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Reported-On_Dest_DSU 


Description: _ The reported-on_destination_DSU is one of the original destination DSUs 
being reported on. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: reported_on_destination 


Presence Rule: Always present, unless the report passed through an FS1 subnet. 


Reported-On_Dest_REN 


Description: The reported-on_destination_REN is the second part of the name of one of the 
original destination DSUs being reported on. This is typically, but not neces- 
sarily, the LU name. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: reported_on_ destination 


Format: Character string 


CGCSGID: 01134-00500 (Character Set AR) 
String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 
Reported-On_Dest_RGN 


Description: The reported-on_destination_RGN is the first part of the name of one of the 
original destination DSUs being reported on. This is typically, but not neces- 
sarily, the network ID. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: reported_on_destination 


Format: Character string 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


536 SNA/Distribution Services Reference 


Reported-On_Dest_User 


Description: The reported-on_destination_user is the name of one of the original destina- 
tion users being reported on. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: reported_on_destination 


Reported-On_Destination 


Description: The reported-on_destination is one of the distribution destinations that is 
being reported on. 


Verbs Supplied on: None 
Verbs Returned on: Get_Exception_Log Entry 
Subtables Found in: SNA_condition_report 


Reported-On_Time 


Description: The reported-on_ftime is the distribution_time that was returned on 
Send_Distribution. 


Verbs Supplied on: None 


Verbs Returned on: Receive_Distribution_Report 


Reporting_DSU 
Description: The reporting DSU is the name of the DSU that generated the report. 
Verbs Supplied on: None 


Verbs Returned on: Receive_Distribution_Report 
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- Reporting_REN - 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Reporting RGN 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


The reporting_REN is the second part of the name of the DSU that generated 
the report. This is typically, but not necessarily, the LU name. 


None 
Receive_Distribution_Report 


Character string 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The reporting RGN is the first part of the name of the DSU that generated the 
report. This is typically, but not necessarily, the network ID. 


None 
Receive_Distribution Report 


Character string 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


Requested_Entry_Number 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


The requested _ entry_number indicates which log entry to return when there 
are more than one with the same distribution identification. For example, a 
requested_entry_number of 4 would retrieve the fourth log entry for a specified © 
distribution identification. 


Get_Distribution_Log Entry, Get_Exception_Log Entry 


None 


Format: Signed binary integer (1-origin) 
Requesting Process 
Description: The requesting_process is the process that is requesting a server action. 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Backout_Server_Object, Initiate_Read, Initiate_Write, 
Query_Last_Byte_Received, Terminate_Restartability 


None 


Character string, except for first byte 
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CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


Restart_Byte 


Description: The restart_byte indicates where the sender is beginning retransmission of 
the server object. 


Verbs Supplied on: _ Initiate_Read, Initiate_Write 


Verbs Returned on: None 


Format: Unsigned binary integer (1-origin); maximum: 2**64 - 2 
Restart_Capable 
Description: The restart_capable flag indicates whether a server is capable of Byte-Count 
Restart. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: server_list_entry 


Format: Enumeration 
Value Meaning 
YES Server is capable of Byte-Count Restart. 
NO Server is not capable of Byte-Count Restart. 
Restart_ID 
Description: The restart_/D identifies a server object being read or written for restart pur- 
| poses. 


Verbs Supplied on: Initiate_Read, Initiate_Write, Query_Last_Byte_ Received, 
Terminate peer ante uny 


Verbs Returned on: None 
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Restartability 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Return_Code 


Description: 


Verbs Supplied on: 


Format: 


Verbs Returned on: 


The restartability parameter indicates whether a server should keep check- 
points on an object that it is reading or writing, in preparation for a later 
restart. 


Initiate_Read, Initiate_Write 
None 


Enumeration 


Value Meaning 
YES If possible, keep checkpoints on this object being 


read/written to allow mid-server object restart. 


NO Do not keep checkpoints on this object. 


The return_code indicates the result of a verb that was issued by an agent or 
by DS. 


None 
All 


Enumeration 


Distribution Return Codes 


OK 
PARAMETER_CHECK 
INVALID_ORIGIN_USER_NAME 
INVALID_REPORT-TO_DEST 
UNSUPPORTED_SERVICE_LEVEL 
INVALID_SERVER_NAME 
INVALID_SERVER_PARAMETER 
INVALID_QUEUE_IDENTIFIER 
/O_EXCEPTION 

QUEUE_EMPTY 
TEMPORARY_SERVER_EXCEPTION 
SPECIFIC_SERVER_EXCEPTION 
AGENT_NOT_DEFINED 
TEMPORARY_EXCEPTION 
TOO_MANY_OUTSTANDING_ SEQNOS 
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RGN 


Description: 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


Operations Return Codes 


OK 
PARAMETER_CHECK 

/O_EXCEPTION 
TEMPORARY_EXCEPTION 
MORE_DATA_TO_COME 
QUEUE_ENTRY_NOT_FOUND 
QUEUE_ENTRY_IN_USE 
QUEUE_EMPTY 
DUPLICATE_QUEUE_ENTRY_CREATED 
CONNECTION_NOT_FOUND 
INVALID_DATA_STRUCTURE_NAME 
INVALID_KEY 

INVALID_STARTING_ POSITION 
DATA_ENTRY_NOT_FOUND 
DATA_ENTRY_IN_USE 
DATA_STRUCTURE_EMPTY 
DATA_STRUCTURE_FULL 
DATA_ENTRY_ALREADY_EXISTS 


Server Return Codes 


OK 
PARAMETER_CHECK 
END_OF_DATA (EOD) 
SPECIFIC_SERVER_EXCEPTION 
/O_EXCEPTION 
TEMPORARY_SERVER_EXCEPTION 
INVALID_SERVER_NAME 
ACCESS_LIST_ENTRY_NOT_FOUND 
NOT_RESTART_CAPABLE 
RESTART_ID_NOT_FOUND 


CANNOT_RESTART_AT_BYTE_POSITION 


OBJECT _NOT_FOUND 


Note: The PARAMETER_CHECK, I/O_EXCEPTION, TEMPORARY_EXCEPTION, and 


OBJECT_NOT_FOUND return codes are issued only by the general server, while 


SPECIFIC_SERVER_EXCEPTION is issued only by a specific server. 


The RGN is the first part of the DSU name. This is typically, but not neces- 


sarily, the network ID. 
None 


None 


directory_entry, DSU_definition_entry, intervention_list_entry 


Character string 
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CGCSGID: | 01134-00500 (Character Set AR) | | 
String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. . | | 
Route 


Description: The route parameter is used to choose among the various route segments 
from this DSU. It is composed of a destination_DSU and the service_parms to 
be used to route to that destination DSU. 


Verbs Supplied on: List_Connections 


Verbs Returned on: None 


Routing_Table_Entry 


Description: The routing_table_entry describes one row in the Routing Table data struc- 
ture. | 


Verbs Supplied on: Add_DSU_Data, List_DSU_Data, Modify_DSU_Data, Remove_DSU_Data 
Verbs Returned on: List_DSU_Data 


Row_Selection_Criteria 


Description: The row_selection_criteria are used to allow the DS system definition verbs to 
| operate on only a portion of a DSU data structure. The row_selection_criteria 
takes the form of a row of the table with some or all of its column values 
specified. The DSU restricts its operations on the data structure to those rows 
that match the row_selection_criteria. 


Verbs Supplied on: List_DSU_Data, Modify_DSU_Data, Remove_DSU_Data 


Verbs Returned on: None 


Scheduling, Data 


Description: : The scheduling data provides the data necessary to do time-of-day scheduling 
for a next-DSU queue. | 7 


Verbs Supplied on: None 
Verbs Returned on: None | 
Subtables Found in: next-DSU_queue_definitions_entry 


Format: | Undefined byte string 
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Seconds 
Description: The seconds parameter gives the seconds portion of the time. 
Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: connection _definitions_entry, time 


Format: Signed binary integer (1-origin) 
Security 
Description: The security service parameter indicates the security requirements for the dis- 


tribution. The combination of this parameter and the 
security_comparison_operator yields the permitted levels of security for the 
distribution. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: report _service_parms, routing_table_entry, service_parms 


Format: Enumeration 
Value Meaning 
LEVEL1 Security is not required. 
LEVEL2 Security is required. 


Security_Comp_Op 


Description: The security_comparison_operator parameter is used to allow a range of 
security service levels for a distribution. The combination of this parameter 
and the security parameter yields the permitted levels of security for the dis- 
tribution. | : 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: report_service_parms, routing _table_entry, service_parms 


Format: Enumeration 


Possible Values. 


REQUIRE_LEVEL_GE 
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Selected_Row 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Sending_State 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


A selected_row is one of the rows that match the row_selection_criteria. 
None 
List_DSU_Data 


The sending_state indicates the current state of a distribution being sent, from 
the DSU’s perspective. 


None 
Query_Distribution Sending, Send_Distribution 


Enumeration 


Value Meaning 

NOT_ASSIGNED There has been no activity on the referenced distrib- 
ution; the sequence number is a valid, unassigned 
value. 

IN_ TRANSIT The agent has issued the sending verb for this distrib- 


ution, and processing of the verb has not yet completed. 


SPEC_SERVER_PENDING The DSU has returned control to the agent after proc- 
essing the sending verb, but specific server operations 
have not yet been completed. 


COMMITTED The DSU has accepted responsibility for the distribution 
after completing specific server operations (if any). 

TERMINATED The distribution could not be sent, and the agent has not 
yet issued Sending Sequence_Completed on this distrib- 
ution. 

COMPLETED The agent has issued Sending Sequence_Completed. 


At this point, the DSU can stop tracking this distribution. 


Seqno_To_Clean_Up 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


The sequence_number_to_clean_up identifies a distribution which has been 
sent by the DSU, but for which the sending agent has not issued 
sending Sequence_Completed to acknowledge the transfer of responsibility. 


None 
Send_Distribution 


Signed binary integer (1-origin) 
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Server 


Description: 


Verbs Supplied on: 


Verbs Returned on: 
Subtables Found in: 


Format: 


Server_Access 


Description: 


Verbs Supplied on: 


Verbs Returned on: 
Presence Rule: 


Format: 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Format: 


Server_Bytes_Received 


The server is the name of the transaction program to be used to read the 
server object at the origin and to store the server object at the destination. 
Server name values are assigned according to the rules of SNA Transaction 
Program names. 


Assign _Read_Access, Backout_Server_Object, Initiate_Read, Initiate_Write, 
Query_Last_ Byte Received, Read, Release_Read_ Access, Send_Distribution, 
Terminate Read, Terminate_Restartability, Terminate_Write, Write 


Get_Distribution_Info, Receive_Distribution 
server_list_entry 


Character string, except for first byte 


CGCSGID: 01134-00500 (Character Set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


The server_access parameter gives the server the information it needs to 
access the server object. 


Assign_Read_ Access, Backout_Server_Object, Initiate_Read, 
Release Read Access, Send_Distribution 


Get_Distribution_Info, Receive_Distribution, Terminate_Write 
May occur only if specific_server_info is absent. 


Undefined byte string 


The server_bytes_received flag indicates whether an agent that issues 
List_Distributions Being Received is interested in how many bytes of the 
server object have been received for each distribution. 


List_Distributions Being Received 
None 


Enumeration 
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Value Meaning 


YES Indicate how many server object bytes have been 
| received for each distribution. 


NO Do not indicate how many server object bytes have been 
received for each distribution. 
Server_Bytes_Remaining 


Description: The server_bytes_remaining flag indicates whether an agent that issues 
List_Distributions Being Sent is interested in how many bytes of the server 
object remain to be sent for each distribution. 


Verbs Supplied on: List_Distributions_Being_Sent 


Verbs Returned on: None 


Format: Enumeration 
Value Meaning 
YES Indicate how many server object bytes remain to be sent 
for each distribution. 
NO Do not indicate how many server object bytes remain to 


be sent for each distribution. 


Server_Instance_ID 


Description: The server_instance_identifier indicates which copy of the specified server is 
reading or writing a particular server object. 


Verbs Supplied on: Read, Terminate _Read, Terminate_Write, Write 
Verbs Returned on: Initiate_Read, Initiate_Write 


| Format: Undefined byte string 


Server_List_Entry 
Description: | The server_list_entry describes one row in the Server List data structure. 
Verbs Supplied on: Add DSU_Data, List_DSU_ Data, Modify_DSU_Data, Remove_DSU_Data 
Verbs Returned on: List_DSU_Data 
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Server_Object_Byte_Count 


Description: The server_object_byte_count is the number of bytes of all the segments of 
the server object. An FS2-capable DSU originating a distribution must either 
supply a correct byte count or omit the field completely; for FS1, the byte 
count need not be accurate. 


Verbs Supplied on: Initiate_Write, Send_Distribution 
Verbs Returned on: Get_Distribution_Info, Receive Distribution 


Format: Unsigned binary integer (1-origin); maximum: 2**64 - 2 


Service_Parms 


Description: The service_parameters describe the types and levels of service requested for 
the distribution. These parameters are provided by the sending agent. 


Verbs Supplied on: List_Adjacent_DSUs, List_Connections, Reroute_Distribution_Copies, 
Send_Distribution 


Verbs Returned on: Get_Distribution_Info, Receive_Distribution, Receive_Distribution_Report 


Session_Reference 


Description: The session_reference identifies the session for a log entry. It may be either a 
sending or receiving session for which the distribution or the exception is 
being logged. | 


Verbs Supplied on: None 
Verbs Returned on: Get_Distribution_Log Entry, Get_Exception_Log Entry 
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Sibling 


Description: The sibling is one of the ID (or T) values necessary to describe the detected 
condition. The structure identified by sibling is a child of the parent identified 
in parent_spec or a sibling of the structure identified in structure_spec. The 
class of the sibling structure is the same as structure_class. The expected 
position, when applicable, is given by structure_position. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: SNA_condition_report 


Presence Rule: Presence is governed by the SNA_report_code. The maximum number of 
occurrences is governed by structure_class. For LENGTH_BOUNDED LT, the 
maximum number is 98; for LENGTH_BOUNDED _LLID, the maximum number is 49. 


Format: Undefined byte string 


SNA_Condition_Report 


Description: The SNA_condition_report describes the condition being reported. The condi- 
tion is always identified by an SNA_report_code. 


Certain conditions can be more fully described by supplementary information. 
Conditions pertaining to one or more structures in a format can have the 
location and contents of each of those structures specified by a 
structure_report. Certain conditions arise from inconsistencies among mul- 
tiple portions of the MU. Each portion is described by a separate 
structure_report. Other information related to the condition can be specified 
in a supplemental_report. 


Verbs Supplied on: None 


Verbs Returned on: Receive _Distribution_Report 


SNA_Report_Code 


Description: The SNA_report_code is an SNA-registered code identifying the condition that 
is being reported. Refer to Appendix E for allowable values and descriptions. 


Verbs Supplied on: None 
Verbs Returned on: Get_Exception_Log Entry 
Subtables Found in: SNA_condition_report 


Format: Byte string, see SNA Formats for further description. 
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Specific_Server_Info 


Description: The specific_server_information contains control information that is passed to 
a specific server to allow it to build a server object. 


Verbs Supplied on: Backout_Server_Object, Initiate Read, Send_Distribution 
Verbs Returned on: Get_Distribution_Info, Receive_Distribution, Terminate_Write 
Presence Rule: Never present when server_access is present. 


Format: Undefined byte string 


Specific_Server_Report 


Description: The specific_server_report reports on the actions of a specific server. It is 
passed from the server to the agent by SNA/DS, either as a returned param- 
eter on a distribution request verb, or on the stand-alone verb 
Obtain _Local_Server_Report. SNA/DS has no control over or knowledge of its 
contents. 


Verbs Supplied on: Backout_Server_Object 


Verbs Returned on: Backout_Server_Object, Get_Distribution_Info, Initiate Read, Initiate_Write, 
Obtain _Local_Server_Report, Query_Distribution_Sending, 
Receive Distribution, Send_Distribution, Terminate_Read, 
Terminate_Restartability, Terminate_Write 


Format: Undefined byte string 


Starting _Queue_Entry_!D 


Description: The starting queue_entry_identifier indicates the first queue entry identifier to 
be considered when processing a List_Queue_Entries verb. 


Verbs Supplied on: List_Control_ MU Queue, List Queue Entries 


Verbs Returned on: None 


Format: Undefined byte string 
Starting_Row_Number 
Description: The starting_row_number indicates the first row of a DSU data structure that 


the DSU should consider in listing a data structure. 
Verbs Supplied on: List_DSU_Data 
Verbs Returned on: None 


Format: Signed binary integer (1-origin) 
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Structure_Byte_ Offset 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


Structure_Class 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Format: 


The structure_byte_offset marks the start of structure_contents within the 
reported-on structure. If structure_segment_num is present, this value is the 
offset from the start of the indicated segment; otherwise, it is the offset from 
the beginning of the structure. 


None 

None 

SNA_condition_report 

Signed binary integer (1-origin) 


The structure_class is the class of the reported-on structure and of any sib- 
lings identified in sibling. For more details on the classes of structures, see 
Appendix G. 


None 
None 
SNA_condition_report 


Enumeration 


Possible Values 


LENGTH_BOUNDED_LLID 
LENGTH_BOUNDED LT 
DELIMITED _LLID 
DELIMITED_LT 
IMPLIED_LLID 
IMPLIED_LT 
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Structure_Contents 


Description: The structure_contents is the portion of the MU that is relevant to the detected 
condition. Typically, the structure_contents will contain the header of the 
structure and at least the beginning of its contents. When the condition can 
be isolated to a portion of the structure, the structure_contents will contain 
only that portion of the structure relevant to the condition. In this case, the 
structure_segment_num and structure_byte_offset |locate the portion of the 
structure relevant to the condition. 


Verbs Supplied on: None 

Verbs Returned on: None 

Subtables Found in: SNA_condition_report 

Presence Rule: Allowed only when structure_state has the value PRESENT. 


Format: Undefined byte string 


Structure_ID_Or_T 


Description: The structure_/D_or_T is the ID or T value of the structure. IDs are the regis- 
tered GDS codepoints and are referred to in SNA Formats. T values are 
architecture-specific values relative to the encompassing ID. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: SNA_condition_report 


Presence Rule: Required except when the siblings contain all pertinent ID (or T) values. In 
this case, the structures specified by each sibling are the structures being 
reported on. 

Format: Undefined byte string 


Structure_Instance 


Description: The structure_instance is used when the structure is one of multiple occur- 
rences of a repeatable structure. The value of sfructure_instance identifies 
the particular instance within a position. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: SNA_condition_report 


Format: Signed binary integer (1-origin) 
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Structure_Position 


Description: The structure_position is either the actual or expected position of this struc- 
ture within its parent in this particular MU. Multiple consecutive instances of 
a repeatable structure share a single position; they can be distinguished by 
structure_instance. 


Verbs Supplied on: None 
Verbs Returned on: None 


Subtables Found in: SNA_condition_report 


Format: Signed binary integer (1-origin) 
Structure_Report 
Description: The structure_report reports on a structure involved in a format-related condi- 


tion. Depending on the condition, the structure_report may describe a struc- 
ture that was present in or absent from the reported-on MU. 


A format condition has its location in the MU pinpointed by a structure_spec 
and a list of parent_spec parameters that define a line-of-descent. The line-of- 
descent begins with the MU and continues down the parent-child hierarchy to 
a level as low as the particular condition warrants. A registered ID must 
appear in a structure_report; if the reported-on structure is not itself a regis- 
tered ID, its line-of-descent must be traced up to include a registered 
ancestor. 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: SNA_condition_report 


Presence Rule: Presence governed by the SNA_report_code. 


Structure_Segment_Num 


Description: The structure_segment_number is the segment of the structure in which the 
condition was detected. 7 


Verbs Supplied on: None 
Verbs Returned on: None 
Subtables Found in: SNA_condition_report 


Presence Rule: Occurs when the beginning of structure_contents was not contained in the first 
segment of the reported-on structure. 


Format: Signed binary integer (1-origin) © 
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Structure_Spec 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


Presence Rule: 


Structure_State 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Subtables Found in: 


The structure_specification contains the identifier (ID or T) and the class of a 
structure. For a structure that occurs multiple times, the instance may also be 
included. The value of the structure_instance identifies the particular 
instance. The position of this structure within its parent structure may also be 
included. This would typically be done when the parent structure contains 
unordered children. 


None 
None 
SNA_condition_report 


Absent only when structure_class has the value LENGTH_BOUNDED LT and the 
repeated values for sibling contain all the pertinent T values. 


The structure_state indicates whether the reported-on structure was present 
or absent. 


None 
None 


SNA_condition_report 


Format: Enumeration 
Value Meaning 
ABSENT The structure being reported on was absent. 
PRESENT The structure being reported on was present. 
Supplemental_Report 
Description: The suppiementai_report contains other information pertaining to a condition. 


Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 
Presence Rule: 


Format: 


The contents of supplemental_report are governed by the SNA_report_code. 
None 

None 

SNA_condition_report 

Presence governed by the SNA_report_code. 


Undefined byte string 
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Termination_Type 


Description: 


Verbs Supplied on: 
Verbs Returned on: 


Format: 


Unit_Of_Work_ID 


Description: 


Verbs Supplied on: 


Verbs Returned on: 


Year 
Description: 
Verbs Supplied on: 
Verbs Returned on: 
Subtables Found in: 


Format: 


The termination_type flag indicates the action the server is expected to take 
regarding the object it has just completed reading or writing. 


Terminate_Read, Terminate_Write 
None 


Enumeration 


Value Meaning 
NORMAL The reading or writing of the server object completed 


normally; any saved checkpoints can be discarded. 


SUSPEND The reading or writing of the server object is being tem- 
porarily suspended. Any checkpoints that have been 
taken should be saved to allow Byte-Count Restart. This 
is the typical value for a Terminate_Read, since Byte- 
Count Restart may be required despite normal com- 
pletion of send-side server operations. 


ABORT The reading or writing of the server object completed 
abnormally; any saved checkpoints can be discarded. 


The unit_of_work_identifier identifies a unit of work for a server. It is assigned 
by the caller, either an agent or DS, on the Initiate_Write verb. The 
unit_of_work_identifier for DS is always the distribution_identification; for an 
agent, it can be any agent-specific byte string. 


Initiate_Read, Initiate_Write, Release Read Access 


None 


The year parameter gives the year portion of the date. 
None 

None 

connection_definitions_entry, date 


Signed binary integer (1-origin) 
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Appendix G. 


Introduction 


Encodings 


This appendix contains the format descriptions of the FS1 and FS2 message 
units. The format descriptions are comprised of two parts: header description 
tables and structure descriptions. A header description table contains the 
header information for each structure associated with a particular message 
unit. A structure description contains a prose description of the structure, bit- 
level representations, and any presence rules or length restrictions associated 
with a particular structure. 


The definition of SNA/Distribution Services (DS) requires a byte-accurate 
description of the formats that must be understood by all DSUs. The DS 
formats are described in terms of encoded fields referred to as “structures” and 
the hierarchical relationship between these structures. In this appendix, the 
header description tables show each structure and its header. Elsewhere in 
this book, the header length is assumed not to be part of the overall structure 
length (e.g., SNA_report_code). 


Structure Classifications 


Fields and groupings of fields are known as structures. They are categorized in 
terms of their hierarchical position (“atomic,” “child,” or ”parent”), the method 
by which their beginning and endings are determined, (length-bounded, delim- 
ited, or implied) and which kind of header is used to identify them (LT or LLID). 
Only certain combinations of characteristics are possible. 


Length-bounded Structures 


Atomic Structures 


Length-bounded structures consist of a header and usually some following 
information. A header may be either two bytes in length, referred to as an “LT” 
(length and type), or four bytes in length, referred to as an “LLID” (length and 
GDS codepoint). In either case, the length bytes include the length of the 
header itself and the following information, if any. For FS1, a header may be 
either two bytes in length, referred to as an “LT,” or five bytes in length, 
referred to as an “LLIDF” (length, GDS codepoint, and format byte). 


In many cases, a structure consists only of its own header followed by data. 
These structures cannot be decomposed, and therefore they are called 
“atomic.” Atomic structures are always length-bounded and may have either 
LT or LLID headers. 


Parent and Child Structures 


Structures can contain other structures within them. The containing structure is 
known as a parent structure and the contained structures are known as 
children. These terms are relative, since a nonatomic child structure itself con- 
tains other structures and is a parent to them. Children of the same parent are 
siblings of each other. Parent structures may be length-bounded, delimited, or 
implied; and may be identified by LTs or LLIDs. 
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Length-Bounded Parent Structures 


In this case, the parent structure has its own header, either an LT or an LLID. 
Its length includes the lengths of all its children plus the length of its own 
header. A length-bounded parent exists both as a logical grouping of its chil- 
dren and as an explicit encoded structure at its own encoding level. 


Delimited Parent Structures 


Sometimes it is convenient to define a group of related structures as existing 
within a parent structure without having that parent structure appear as a 
length-bounded structure in the message. The beginning and end of the parent 
are defined by its first and last children. These children are known as delim- 
iters, the first child is the prefix delimiter and the last is the suffix delimiter. 
Delimiter children are length-bounded and must be present. They may be null, 
that is, with an LT of length =2 or an LLID of length=4. When the children’s 
headers are LTs, the parent is classified as a delimited LT structure. When 
they are LLIDs, the parent is a delimited LLID structure. 


Implied Parent Structures 


It is possible to define a set of related structures as children of a parent struc- 
ture where the existence and boundaries of the parent are implied by the exist- 
ence and order of certain child structures. This set of children may occur 
within the parent structure, either ordered or unordered, until a structure occurs 
that is not an element of this set. This break in sequence implies the boundary 
between parent structures. Depending on its children’s headers, an implied 
parent is classified as either implied LT or implied LLID. 


Segmented Structures 


Length-bounded LLID Structures may be either segmentable or non- 
segmentable. For segmentable structures, the most significant bit of the LL 
bytes indicates whether any particular segment is the last (bit is equal to 0) or 
not last (bit is equal to 1) segment of the structure. The ID bytes of the 
segmentable structure are present on the first segment only. 


For FS1, segmentation is indicated by the contents of the F byte (the fifth byte 
of the LLIDF header). Structures may be segmented when the most significant 
bit of the F byte is on. If the most significant bit is on, then three more bytes, 
the ISS bytes, follow the LLIDF header. The ISS bytes indicate whether a 
particular segment is the last segment of a structure. In each segment except 
the last segment of a structure, the | byte contains X’20’. In the last segment of 
a structure, the | byte contains X’00’. The SS bytes contain X’0000’. 


Properties of Parent Structures 


Order 


A parent structure may have either ordered or unordered children. Ordered 
children occur in the parent structure in the same order as they are described 
in the format description table. Unordered children may occur in the parent 
structure in any order. 
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Unrecognized Children 
Future enhancements to the formats might add structures that will not be recog- 
nized by implementations of the current format definitions. The current format 
must specify for each parent whether or not unrecognized child structures are 
allowed. If they are allowed, the definition must specify how long they might 
be. When unrecognized structures are found where they are allowed, they 
must be passed through without change at intermediate locations and grace- 
fully ignored at final destinations. Unrecognized structures are identified by 
either LT or LLID headers, being of the same type as their siblings. 


Number of Children 
The number of children within a parent may range from a required minimum to 
an allowed maximum. For example, a parent might have several children, each 
defined with an occurrence of 0-1, and a number of children defined as 1. This 
means that any one, but only one, child is allowed. 


Header Description Table 
The header information and primary syntax associated with each structure are 
formally described in tabular form. These header description tables represent 
the formatting information required to either parse or build DS structures. 


Structure Name 
The first column of the header description table identifies DS structures, by 
name, and illustrates their hierarchical relationship by indentation of the 
column entries. The order of the structure entries in the table represents, 
unless specified otherwise, the order in which the structures appear in a DS 
message unit. 


Structure Reference (Struct Ref) 
As header information and primary syntax are described in the header 
description of a particular table, the semantics, bit representations, presence 
rules, and other characteristics are described formally in the structure 
description. This column contains a reference page number to where this 
structure information is found. 


Structure Class (Struct Class) 
Structures are classified as either length-bounded LLIDs (ID), length- 
bounded LTs (T), delimited LLIDs (Del-ID), delimited LTs (Del-T), implied LLIDs 
(Imp-ID), or implied LTs (Imp-T). 


A structure classified as delimited must contain at least two required, length- 
bounded children that act as the prefix (pfx) and suffix (sfx) of the delimited 
structure. The °’/pfx” notation indicates the length-bounded child struc- 
ture that serves as the prefix for its parent delimited structure. The ”/sfx’” 
notation indicates the length-bounded structure that serves as the suffix for 
its parent delimited structure. 


A structure classified as implied uses an identified child to identify the begin- 
ning of a sequence of children. The ”/idc” notation indicates the length- 
bounded structure that serves as an identified child of its parent implied 
structure. | 
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ID/T 


Length 


Occurrences 


Children 


The same notation is applied to the Format Set 1 encodings. Structures in 
FS1 are classified as either length-bounded LLIDFs (IDF), length- 
bounded LTs (T), delimited LLIDFs (Del-IDF), delimited LTs (Del-T), implied 
LLIDFs (Imp-IDF), or implied LTs (Imp-T). 


The ”/seg” notation indicates that segmentation is allowed. 


This column contains the ID or T value within the header, in hexadecimal. To 
indicate that a delimited structure is identified by its prefix, the notation “pfx” is 
used. To indicate that an implied structure is identified by one of its children, 
the notation “idc,” for identified child, is used. 


This column describes the length verification that would be appropriate at pres- 
entation services time. The range of length values specifies the minimum and 
maximum lengths of structures that an implementation is required to receive. 
For structures that allow unrecognized children, the maximum length value 
accommodates the possibility of these yet-to-be-defined structures. On the 
sending side, the maximum length value for a particular structure may be 
determined by subtracting the unrecognized reserve, if unrecognized children 
are allowed, from the maximum length. 


Note: An asterisk denotes length restrictions for a particular structure. Length 
restrictions are detailed in the corresponding structure description. 


Multiple occurrences of DS structures may or may not be permitted. A value of 
“4 - <some number>” in this column indicates the allowed range of occur- 
rences of the corresponding structure. A value of ”>1” indicates that there is 
no architecturally defined maximum. A value of.”1” in this column indicates 
that only a single instance of the corresponding structure is appropriate. A 
value of "0 - 1” indicates that an instance of the corresponding structure is 
optional. : 


Note: An asterisk denotes presence rules for a particular structure. Presence 
rules are detailed in the corresponding structure description. 


Unrecognized Children Allowed (Unrec): An entry of ”Y” in the “Unrec” column 
indicates that the corresponding structure tolerates unrecognized child struc- 
tures. An entry of ”N” indicates that the particular structure tolerates only the 
architecturally-defined child structures. An entry of ”—” indicates that unrecog- 
nized children are not applicable to the particular structure. By definition, 
atomic structures do not contain children, recognized or not. 


Order: A value of ”Y” in this column indicates that children are ordered, a 
value of “N” indicates that children are unordered, and a value of "—” indicates 
that no children are present. 


Note: if a structure is atomic, this column is not applicable. 
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Number (Num): Each parent structure contains a certain number of different 
children. This column specifies the minimum and maximum number of different 
children for a particular parent structure. The maximum number also accounts 
for unrecognized children, if they are allowed within the parent structure. This 
column does not account for multiple occurrences of a particular child structure 
within the parent structure. The number of occurrences of each child is indi- 
cated in the “Occurrences” column. 


Subtable: Sometimes the need to divide large tables into subtables becomes 
apparent, particularly when common children appear frequently within different 
header description tables. This column contains a reference page number to 
where these common children are described. 


Structure Description 
The structure description is referenced by a page number appearing in the 
"Structure Reference” column corresponding to each structure in the header 
description table. This description contains information pertaining to the data 
portion of a particular structure. Prose descriptions, presence rules, and 
semantics associated with the corresponding entry in the header description 
table may appear in the structure description. 
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Header Description Tables for FS2 Message Units 


DISTRIBUTION TRANSPORT MESSAGE UNIT (DTMU) 


Table 69 (Page 1 of 2). Distribution Transport Message Unit 


Struct Struct Occur- 


Dist_Transport_MU 
Transport_Prefix 
Hop_Count 
MU_ID 
MU_Instance_Number 
Transport_Command 


4 5 
= 
i? f] 
® 
ve} 


Dist_Flags 
Service_Parms 
Server_Obj_Byte_Count 
Origin_Agent 
Server 
Origin_DSU 
Origin_RGN 
Origin _REN 
Origin_User 
Origin_DGN 
Origin_DEN 
Seqno_DTM 
Supplemental_Dist_Infot 
Agent_Correl 
Report-To_DSU 
Report-To_RGN 
Report-To_REN 
Report-To_User 
Report-To_DGN 
Report-To_DEN 
Report_Service_Parms 
Report-To_Agent 
Dest_Agent 


HAHAHA AHHH HAHAHA TH AHA AH AAA AAA AAS 


Unrecognized_Reserve 
Dest_List 
Dest 
Dest_DSU 
Dest_RGN 


oO 
=~ 
tee] 
@ 
© 
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Table 69 (Page 2 of 2). Distribution Transport Message Unit 


Structure Name Struct | Struct ID/T Length Occur- 
Ref Pg | Class rences 
583 02 z 


Dest_REN 3-10 
Dest_User 583 02 8-22 

Dest_DGN 583 01 

Dest_DEN 584 


584 
584 
584 
605 
584 
* Refer to FS2 Structure Descriptions starting on page 568 for presence rules and length restrictions. 


Agent_Object 
Server_Object 


Supplemental Dist_Info2 


Unrecognized_Reserve 
DS_Suffix 
Note: 
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DISTRIBUTION REPORT MESSAGE UNIT (DRMU) 


Table 70 (Page 1 of 2). Distribution Report Message Unit 


Struct | Struct occur |———Chldren 
Structure Name Ref Pg ie || | Length ee 


Dist_Report_MU 
Report_Prefix 
Hop_Count 
MU_ID 
MU_Instance_Number 
Report_Command 25-4096* 
Service_Parms 5-32 
Report-To_Agent 3-10 
Reporting DSU 8-22 
Reporting _RGN 3-10 
Reporting REN 3-10 
Report_DTM 10-13% 
Unrecognized_Reserve 2-4015 
Report-To_DSU_User 12-48 
Report-To_DSU 8-22 
Report-To_RGN 3-10 
Report-To_REN 3-10 
Report-To_User : 8-22 
Report-To_DGN 3-10 
Report-To_DEN 3-10 
Report_Information | 18-4096 
Reported-On_Origin_DSU 8-22 
Reported-On_Origin_RGN 3-10 
Reported-On_Origin_REN 3-10 
Reported-On_Origin_User 8-22 
Reported-On_Origin_DGN 3-10 
Reported-On_Origin_DEN 3-10 
Reported-On_Seqno_DTM 14-17 
Reported-On_Supp_Dist_Info1 3-10 
Reported-On_Agent_Correl 3-130 
Reported-On_Origin_Agent | 3-10 
Reported-On_Dest_Agent 3-10 
Receiving _DSU 8-22 
Receiving RGN 3-10 
Receiving REN 3-10 


Unrecognized_Reserve 2-3849 
SNA_Condition_Report | 10-32767 
Reported-On_Supp_Dist_Info2 5-32767 
Unrecognized_Reserve 4-32767 
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Table 70 (Page 2 of 2). Distribution Report Message Unit 


ny ee i Px post 

Structure Name Ref Pg | Class Length aia Unree| order Sub 
Table 

DS_Sutfix ee LC a a es 


Note: * Refer to FS2 Structure Descriptions starting on page 568 for presence rules and length restrictions. 


DISTRIBUTION CONTINUATION MESSAGE UNIT (DCMU) 


Table 71. Distribution Continuation Message Unit 


ene eee occur. |——___Sthilren 
srearstere |B |e wr |S nr 
aple 


Dist_Continuation_MU 
Continuation_Prefix 
MU_ID 
MU_Instance_Number 


Restarting_Byte_Position 
Agent_Object 
Server_Object 
Supplemental_Dist_Info2 


5-32767 
=5 
5-32767 
4-32767 
4 
* Refer to FS2 Structure Descriptions starting on page 568 for presence rules. 


Unrecognized_Reserve 
DS_ Suffix 
Note: 
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SNA CONDITION REPORT 


Table 72. SNA Condition Report 


Structure Name 


SNA_Condition_Report 
SNA_Report_Code 
Structure_Report 

Structure_State 
Structure_Contents 


Parent_Spec 
Parent_ID_Or_T 
Parent_Class 
Parent_Position 
Parent_Instance 

Structure_Spec 
Structure_ID_Or_T 
Structure_Class 
Structure_Position 
Structure_Instance 

Structure_Segment_Number 

Structure_Byte_Offset 

Sibling List 

Unrecognized_Reserve 

Reported-On_Dest_List 

Reported-On_Dest_Prefix 

Reported-On_Dest 
Reported-On_Dest_DSU 

Reported-On_Dest_RGN 
Reported-On_Dest_REN 
Reported-On_Dest_User 
Reported-On_Dest_DGN 
Reported-On_Dest_DEN 
Reported-On_Dest_Suffix 
Supplemental_Report 


Unrecognized_Reserve 


594 
594 


HHAHAAHA HAHAHAHAHA A AA AAA AA 


ae Sean occur. L—___Sthildrem 
Ref Pg | Class ee Length | ences Sub 
Table 
593 ID 1 Y Y 


10-32767 
6 
14-255 
3 
3-100 
5-17 


3-100 
2-241 
12-11268 
2 
8-5654 
2-22 
3-10 
3-10 


605 T 


Note: * Refer to FS2 Structure Descriptions starting on page 568 for presence rules and length restrictions. 
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SENDER EXCEPTION MESSAGE UNIT (SEMU) 


Table 73. Sender Exception Message Unit 


ae ae o Children 
ru ru ccur- 
able 


Sender_Exception_MU 1578 10-256 
2-236 
Table 74. Receiver Exception Message Unit 


SNA_Report_Code 
* Refer to FS2 Structure pees starting on page 568 for presence rules. 
ae occur. | ———-_eilaren 
able 


MU_ID 
Receiver_Exception MU 


MU_Instance_Number 


Unrecognized Reserve 
Note: 


RECEIVER EXCEPTION MESSAGE UNIT (REMU) 


Receiver_Exception_Command 


Sender_Retry_Action 
MU_ID 
MU_Instance_Number 


Receiving DSU 


Receiving RGN 


Receiving_REN 


Unrecognized_Reserve 


Unrecognized_Reserve 
SNA_Condition_Report 
Note: 


* Refer to FS2 Structure Descriptions starting on page 568 for presence rules. 
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COMPLETION QUERY MESSAGE UNIT (CQMU) 


Table 75. Completion Query Message Unit 


| Children 
22 CoS 
Table 
Completion_Query_MU 1579 eae 
MU_ID 
MU_Instance_Number 
Unrecognized_Reserve 2-242 
Table 76. Completion Report Message Unit 


COMPLETION REPORT MESSAGE UNIT (CRMU) 
ee occur L____ehlldren 
Structure Name Ref Pg | Class Length ccncee ae Sub 
Table 
Completion_Report_MU 
Indicator_Flags 
MU_ID 
Table 77. Purge Report Message Unit 
ae a ee 
Structure Name Ref Pg | Class ID/T Length ae eee Sub 
| Table 
Purge Report_MU 157E 10-256 Y y 
ca — — 


HHaac 


Last_Byte_Received 


Unrecognized_Reserve 
Note: 


* Refer to FS2 Structure Descriptions starting on page 568 for presence rules. 


PURGE REPORT MESSAGE UNIT (PRMU) 


MU_Instance_Number 
Last_Structure_Received 
MU_ID 
Unrecognized_Reserve 
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RESET REQUEST MESSAGE UNIT (RRMU) 


Table 78. Reset Request Message Unit 


Struct Struct a a 
Structure Name Ref Pg | Class Length Sana e Sub 
Table 
we :F Ee _ eT 


MU_ID 
RESET ACCEPTED MESSAGE UNIT (RAMU) 


Reset_DTM 


Table 79. Reset Accepted Message Unit 


Struct | Struct 
Structure Name Ref Pg | Class Length ___ a 
Table 
Reset_Accepted_MU 1586 21-23 
11-13 


MU_ID 
Reset_DTM 
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_FS2 Structure Descriptions 


Dist_Transport_MU 


Description: 


Length Restriction: 


Transport_Prefix - 


Description: 


Hop_Count 


Description: 


Format: 


MU_ID 


Description: 


Presence Rule: 


Format: | 


Description: 


Presence Rule: 


Format: 


MU_Instance_Number 


The distribution_transport_message_unit transports agent and/or server 
objects for distribution to one or more users or application programs. 


The minimum length of a dist_transport_MU originated by an FS2 DSU is 54 
bytes. This is due to the length restriction on the Seqno_DTM. 


The transport_prefix identifies the beginning of the dist_transport_MU. This 
structure carries information that changes from DSU to DSU. 


The hop_count is the remaining number of hops that may be traversed by a 
DS distribution on its way toward its destination DSUs. The hop count is set 
by the origin DSU in the DTMUs and by the reporting DSUs for the DRMUs. 
The hop_count is decremented by 1 in every DSU through which the 
distribution passes. If the hop count reaches 0 at an intermediate DSU, 
exception processing is invoked. 


Signed binary integer (1-origin) 


The message_unit_identifier is a number that uniquely identifies a distribution 
MU throughout its existence. An MU exists for only one hop, from one DSU to 
the adjacent DSU. In REMUs and SEMUs, the MU_ID refers to a distribution 
MU. An MU_/D is unique only for a particular LU name, mode name combina- 
tion. 


If the MU_ID is absent, exception reporting may not be requested. 


Signed binary integer (1-origin) 


The message_unit_instance_number identifies the instance of a particular dis- 
tribution message unit and its corresponding MU_ID. 


Precluded if an MU_ID is not present; otherwise, required. 


Signed binary integer (1-origin) 
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Transport_Command 


Description: 


Length Restriction: 


Dist_Flags 
Description: 
Note: 


Format: 


The transport_command contains the control information used by the distrib- 
ution service to transport the distribution. 


The minimum length of a transport_command originated by an FS2 DSU is 30 
bytes. This is due to the length restriction on the Seqno_DTM. 


The distribution flags indicate services requested by the origin agent. 


If exception reporting is requested, the MU_ID is always present. 


Bit string 
Byte Bit 
0-1 
2 
0 
1-7 
3 
0-7 
4 
0-7 


Content 
LT header 


Flags (bits 0-7) that must be understood and honored by 
all DSUs 

Exception report flag indicating whether an exception 
report is to be sent if the distribution is aborted: 

0 no exception report to be sent (default) 

1 exception report to be sent 

Reserved 


Flags (bits 0-7) that must be understood and honored by 
destination DSUs, but that can be ignored by interme- 
diate DSUs 

Reserved 


Flags (bits 0-7) that are ignored by DSUs if not under- 


stood 
Reserved 
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Service_Parms 


Description: The service _ parameters structure describes the types and levels of service 
requested for the distribution. The parameters in this structure are provided 
by the origin agent. The service_parameters used in the DTMU and the DRMU 
are similar; the differences in such usage and the default values used for 
absent service_parameter (SP) triplets are discussed under the individual trip- 
lets below. Refer to Appendix C for details on the base and option subsets 
for service_parameters. The default values specified below are assumed for 
absent service_parameter (SP) triplets. _ 


In FS1, the service_parameters are specified by the origin agent in Dist_MU 
type TRANSPORT. The specification for deriving the service_parameters for 
Dist_MU type REPORT is found in the description of report_service_parameters 
on page 579. 


Format: Special format consisting of ordered, optional, SP triplets of the following 
| general structure: 


Byte Bit Content 


0 Parameter type: 
All parameter type byte values are defined by or 
reserved for SNA/DS. 


1 ! Comparison operator: | 
0-3 1100 REQUIRE_LEVEL_GE 
1110 REQUIRE_SUPPORT_FOR 
| Note: All other values for bits 0-3 are reserved. 
4-7 Reserved 
2 _ Value: 
The meaning of this byte depends on the parameter 
type. | 
Byte Content 
0-1 _ LT header 
2-31 Up to 10 different service_parameter (SP) triplets may be carried in 


one distribution. Each triplet, when present, appears in ascending 
sequence of parameter type. For FS2, the capacity triplet is not 
used in the DRMU. For FS1, the capacity triplet is used. For FS2, 
all service parameters are optional in both the DTMU and the 
-_DRMU. For FS1, the first three parameters are present in both 
Dist_MU types TRANSPORT and REPORT. The architecturally defined 
service parameters are given below: — 
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Priority SP Triplet 


Byte 


0 


Content 

X’01’ 

X’CO’ = REQUIRE_LEVEL_GE 

X’FO’ FAST (default) 

X’DO’ CONTROL 

X’80" DATA.16 ~~ (can be treated as DATAHI) 
X’78’ =: DATA_15 (can be treated as DATAHI) 
X’70’ sz DATA_14 (can be treated as DATAH!) 
X’68" =DATA_13 (can be treated as DATAH)) 
X’60" = DATA_12 (DATAHI) 

X’58" = DATA_11 (can be treated as DATAHI) 
X’50" ~=DATA_10 (can be treated as DATAHI) 
X’48’ DATA9 (can be treated as DATAHI) 
X’40’ DATA_8 (can be treated as DATALO) 
X’38" = DATA_7 (can be treated as DATALO) 
X’30" DATAS& (can be treated as DATALO) 
X’28’ =DATA5 (can be treated as DATALO) 
X’20’ = DATA_4 (DATALO) 

X'18’ = DATA_3 (can be treated as DATALO) 
X’10’  DATA_2 (can be treated as DATALO) 
X’08’—s DATA_1 (can be treated as DATALO) 
Note: All other values are reserved. 


Protection SP Triplet 


Byte 


0 


Content 

X’02’ 

X’CO’ REQUIRE_LEVEL_GE 

X’10" —- LEVEL’ (default when Priority SP is GE X’E0’): 
safe store may be performed. 

X’30’ ~=LEvEL2 (default when Priority SP is LT X’E0’): 
safe store must be performed. 

Note: All other values are reserved. 
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Capacity SP Triplet 


Byte Content 

0 X’03’ 

1 X’CO’  REQUIRE_LEVEL_GE 

2 Capacity value is the exponent of the power of 2 that represents 
the value of the required capacity for the server_object in the 
DTMU: 


X’00" ZERO (default when Priority SP is GE X’E0’) 
used if there is no server_object 
in dist_transport_MU. 
X’'14’ 1MB one megabyte 
X’16’  4MB 
X’18’ 416MB (default when Priority SP is LT X’E0’) 
Note: All other values are reserved. 


1, In FS2, the Capacity SP triplet occurs only in a 
DTMU. 
2. Receiving FS2 DSUs are always able to 


receive a capacity level of INDEFINITE (designated 
by X’EOFF’ in bytes 1-2). 

Originating FS2 DSUs never generate the 
capacity level of INDEFINITE. The level 

replacing INDEFINITE is 16MB (X’C018’). 


3. The capacity requirement is for the 
server_object, and does not include the 
capacity needed to store and handle the 
other structures of the DTMU. 


4, Implementations may accept other capacity 
levels as long as they can route the 
distribution responsibly. 


Security SP Triplet 

Byte Content 

0 X04’ 

1 X’CO’ REQUIRE_LEVEL_GE 


2 X’01’ —_LEveL1 (default): security is not required. 
X’20’ +LEVEL2: security is required. . 
Note: All other values are reserved. 
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Server_Obj_Byte_Count 


Description: 


Presence Rule: 


Format: 


Origin_Agent 


Description: 


Format: 


Server 


Description: 


Presence Rule: 


Format: 


Origin_DSU 


Description: 


The server_object_byte_count is the number of bytes of all the segments of 
the server_object. An FS2-capable DSU originating a distribution either sup- 
plies a correct byte count, or omits the field completely; for FS1, the byte 
count need not be accurate. 


Optional when the server_object is present; otherwise, precluded. 


Unsigned binary integer (1-origin) 


The origin_agent is the transaction program at the DSU at which the distrib- 
ution originated. 


Character string, except for first byte 


CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


The server is the name to be used to store the server_object at the destina- 
tion. 


In FS2, optional when the server_object is present; otherwise, precluded. If 
optional and absent, the general server TP name is the default. In FS1, 
required when the server_object is present. 


Character string, except for first byte 


CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges tn value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 


The origin_DSU is the name of the DSU at which the distribution originated. 
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Origin_RGN 


Description: 


Format: 


Origin_REN 


Description: 


Format: 


Origin_User 


Description: 


Origin_DGN 
Description: 


Note: 


Format: 


The origin_RGN is the first part of the name of the DSU at which the distrib- 
ution originated. This is typically, but not necessarily, the network ID. 


Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The origin_REN is the second part of the name of the DSU at which the distrib- 
ution originated. This is typically, but not necessarily, the LU name. 


Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X°40’) characters 
are not allowed. 


The origin_user is the user name of the originator of the distribution. 


The origin_DGN is the first part of the user name of the distribution originator. 


For FS1, when the Dist_MU is of type REPORT and the distribution report was 
generated by DS, null user names will occur. 


Character string 


CGCSGIDs: 


String Conventions: 


01134-00500 (base), 00930-00500 (enhanced character set) 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are not 
allowed, trailing space characters are not sig- 
nificant, and imbedded space characters are 
significant. 
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Origin_DEN 


Description: The origin_DEN is the second part of the user name of the distribution origi- 
nator. 

Note: For FS1, when the Dist_MU is of type REPORT and the distribution report was 
generated by DS, null user names will occur. 

Format: Character string 
CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced character set) 


String Conventions: 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are not 
allowed, trailing space characters are not sig- 
nificant, and imbedded space characters are 
significant. 


Seqno_DTM 


Description: The sequence_number/date-time, in combination with the origin_agent, 
origin_user, and origin_DSU, uniquely identifies the distribution. The 
sequence number is the number assigned to the distribution by the origin 
agent. For FS2, the number ranges from 1 to (2**31)-1. For FS1, the number 
ranges from 0 (for report MUs) to 9999. Refer to Appendix D for migration 
details. The date of the distribution is assigned by the origin agent; the time 
of the distribution is assigned by the origin DSU. The offset from GMT for 
local time is included. 


Note: FS2 tolerates sequence numbers with value 0 in message units that had, at 
some point, come from an FS1 network and had already specified a sequence 
number of 0 (i.e., DIA application status reports). However, sequence 
numbers with value 0 are never originated from within an FS2 network. 


Length Restriction: Originating FS2 DSUs generate a GMT-based time. The minimum length for 
seqno_DTM is therefore 15 (1-origin). 


Format: : Byte string 
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15 


16 


Examples: 


Content 
LT header © 


SEQNO 
Signed binary integer limited to (2**31)-1_ 


DATE 

Year, in binary (e.g., 1989 is encoded as X’07C5’) 

Month of the year, in binary (values from 1 to 12 are valid) 
Day of the month, in binary (values from 1 to 31 are valid) 


TIME 

Hour of the day, in binary (values from 0 to 23 are valid) 

Minute of the hour, in binary (values from 0 to 59 are valid) 
Second of the minute, in binary (values from 0 to 59 are valid) 
Hundredth of the second, in binary (values from 0 to 99 are valid) 


GMT FLAGS 
Indicates that specified TIME is GMT and identifies whether offsets 
from GMT are required to calculate local time. (Equivalent EBCDIC 
characters are shown in parentheses.) 
X’E9’ (z) no offset required 
X’4E" (+) add required offset to GMT to get 
local time 
X’60’ (-) subtract required offset from GMT to get 
local time 
Note: All other values are reserved. 


Hour offset from GMT, in binary, occurs when GMT flag # X’E9’ 
(values from 0 to 23 are valid) | 
Minute offset from GMT, in binary, occurs when GMT flag # X’E9’ 
(values from 0 to 59 are valid) 


A 9-byte date-time encoding is a date-time followed immediately by an EBCDIC 
"Z” and is considered to be GMT. Thus, 12:00GMT on 2 January 1988 would be 


X'07C401020COQOGRGES' 
yyyyMMddHHmmsshhZ 


An 11-byte date-time encoding is a date-time followed immediately by an 
EBCDIC ”+” or ”-” and two 1-byte binary numbers, and is considered to be 
GMT and the offset from GMT to local time. Thus, 7:00am on 2 January 1988 in 
New York would be 12:00GMT - 5 hours, or 


Supplemental_Dist_Info1 


X'07C401020C000000600500 ! 
yyyyMMddHHmmsshh- HHmm 


Description: The supplemental_dist_infof structure is reserved for future use. 


Format: Character string 
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Agent_Correl 


Description: The agent_correlation is a string supplied by the origin agent. DS is not 
aware of its contents. 


Format: Undefined byte string 


Report-To_DSU 


Description: The report-to_DSU is the name of the DSU to which distribution reports are to 
be sent. If both report-to_DSU and report-to_user are absent in the DTMU, the 
values generated in the DRMU for these structures default to the origin. If 
only report-to_DSU is present in the DTMU, then any report is sent to that 
DSU. If only report-to_user is present in the DTMU, then the reporting DSU 
will refer to its directory to determine report-to DSU. For FS1, this information 
is valid only if Dist_MU is of type TRANSPORT. 


Report-To_RGN 


Description: The report-to_RGN is the first part of the DSU name to which distribution 
reports are to be sent. For FS1, this information is valid only if Dist_MU is of 
type TRANSPORT. This is typically, but not necessarily, the network ID. 


Format: - Character string 


CGCSGID: 01134-00500 (character set AR) 
String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 
Report-To_REN 


Description: The report-fo_REN is the second part of the DSU name to which distribution 
reports are to be sent. For FS1, this information is valid only if Dist_MU is of 
type TRANSPORT. This is typically, but not necessarily, the LU name. 


Format: Character string 


CGCSGID: 01134-00500 {character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


Note: If a product chooses to implement DGN=REN, the 
enhanced character set (ECS) subset is implemented in a 
particular network, and any DGN contains an ECS char- 
acter that is not an element of character set AR, then ECS 
characters may occur in this structure. 
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Report-To_User 


Description: The report-to_user is the name of the user to which distribution reports are to 
be sent. If both report-to_user and report-to_DSU are absent in the DTMU, the 
values generated in the DRMU for these structures default to the origin. If 
only report-to_user is present in the DTMU the reporting DSU refers to its 
directory to determine report-to_DSU. For FS1, this information is valid only if 
Dist_MU is of type TRANSPORT. 


Report-To_DGN 
Description: The report-to_DGN is the first part of the user name to which distribution 
reports are to be sent. For FS1, this information is valid only if Dist_MU is of 
type TRANSPORT. 
Format: Character string 


CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced character set) 
String Conventions: | 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are not 
allowed, trailing space characters are not sig- 
nificant, and imbedded space characters are 
significant. 


Report-To_DEN 


Description: The report-to_DEN is the second part of the user name to which distribution 
reports are to be sent. For FS1, this information is valid only if Dist_MU is of 
type TRANSPORT. | | - 3 


Format: Character string 


CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced character set) 
String Conventions: | 
Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are not 
allowed, trailing space characters are not sig- 
nificant, and imbedded space characters are 
significant. 
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Report_Service_Parms 


Description: The report_service_parameters structure describes the service requested for 
the distribution report by the origin agent when the agent wants to override 
the service_parameters that would be routinely generated by the reporting 
DSU for the report MU. If report_service_parameters are specified, they are 
used as the service_parameters in any DRMUs that are generated as part of 
the distribution. If the origin agent does not specify one or more of the 
report _service_parameters, a DSU that generates a report derives appropriate 
service_parameters for the DRMU from the service_parameters in the DTMU. 


For FS2, the comparison operators and values derived for the protection and 
security parameters are the same as those specified (explicitly or implicitly) in 
the DTMU. For FS1, the comparison operators and values derived for the pro- 
tection, capacity, and security parameters are the same as those specified in 
the Dist_MU type TRANSPORT. 


For the priority service parameter, the value derived is either FAST Or CONTROL. 
FAST is used if the DTMU specified FAST priority; CONTROL is used if the DTMU 
specified a DATA_N priority. CONTROL priority is used only in DRMUs; it may not 
be specified for the priority service parameter in a DTMU. Ifthe origin agent 
explicitly specifies a value for the priority report service parameter, the value 
may be FAST, CONTROL, Or DATA_N. The comparison operator for the priority 
service parameter is always REQUIRE_LEVEL_GE. 


Format: Special format consisting of ordered, optional report _service_parameter trip- 
lets of the same general structure as for service_parameters. See 
service_parameters on page 570. 


Byte Content 
0-1 LT header 
2-31 Up to 10 different report_service_parameter (RSP) triplets may be 


carried in one distribution. Each triplet, when present, appears in 
ascending sequence of parameter type. For FS2, the capacity 
triplet is not used in the DRMU, and therefore the capacity RSP is 
never specified. For FS1, the capacity triplet is used. For FS2, all 
service parameters are optional in both the DTMU and the DRMU. 
For FS1, the first three parameters—priority, protection, and 
capacity—are present if report service parameters are to be speci- 
fied. | 
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Priority RSP Triplet 


Byte Content 

0 X01’ 

1 X’CO’ + REQUIRE_LEVEL_GE 
2 X’FO’ FAST 


X’DO’ =CONTROL 

X’80’ DATA.16 (can be treated as DATAH)) 
X’78" DATA15 (can be treated as DATAHI) 
X’70"  DATA.14 ~—s {can be treated as DATAHI) 
X’68’  DATA.13 ~— (can be treated as DATAHI) 
X’60’ =DATA.12 = (DATAH!) 

X’58’—s ;DATA_11 (can be treated as DATAHI) 
X’50° DATA10 ~= (can be treated as DATAH)) 
X’48"  DATA_9 (can be treated aS DATAH!) 
X’40’ _ DATA_8 (can be treated as DATALO) 
X’38’ = DATA_7 (can be treated as DATALO) 
X’30° DATA6 (can be treated as DATALO) 
X’28’ = DATA_5 (can be treated as DATALO) 
X’20" = DATA4 (DATALO) 

X’18’ DATA.3 (can be treated as DATALO) 
X10’ DATA_2 (can be treated as DATALO) 
X’08" = DATA_1 (can be treated as DATALO) 
Note: All other values are reserved. 


Protection RSP Triplet 


Byte Content 

0 X’02’ 

1 X’CO’  REQUIRE_LEVEL_GE 

2 X10’ LEVEL1: safe store may be performed. 


X’30’ LEVEL2: safe store must be performed. 
Note: All other values are reserved. 
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Report-To_Agent 


Description: 


Format: 


Capacity RSP Triplet (not present in FS2) 


Byte Content 
0 X03’ 
1 X’CO’ REQUIRE_LEVEL_GE 


2 X’00’ 


ZERO 


Notes: All other values are reserved. 


Also, All FS1 implementations are able to receive 
distribution reports of FOUR_K capacity (X’0C’). 
New FS1 implementations always send 
distribution reports of ZERO capacity. 


Security RSP Triplet 


Byte Content 

0 X’04’ 

1 X’CO’ REQUIRE_LEVEL_GE 

2 X’01’ ~LEVEL1: security is not required. 
X’20’ LEVEL2: security is required. 
Note: All other values are reserved. 


The report-to_agent is the name of the application transaction program to be 
started after the report is queued for delivery. If report-to_agent is absent in 
the DTMU, the value specified in the DTMU for origin_agent is used in the 
DRMU for report-to_agent. 


Character string, except for first byte. 


CGCSGID: 


01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 


are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 
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Dest_Agent 


Description: The destination_agent is the transaction program at the destination DSU 
to which the distribution is tobe delivered. If dest_agent is absent in 
the DTMU, the value specified for origin_agent is assumed to be the 


dest_agent. 
Format: Character string, except for first byte 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When ihe first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 
byte. 

Dest_List 


Description: The destination list is the list of destinations for the distribution, which can 
contain up to 256 destinations. Each destination is a dest_DSU with or without 
a dest_user, expressed as (dest DSU (,dest_user)). For single-destination dis- 
tributions and distribution reports, the dest_list contains only one destination. 


Either a flat destination list, of the form 
(dest_DSU (dest_user)), ...,(dest_DSU (dest_user)), ... 
or a factored destination list, of the form 
(dest_DSU (dest_user, dest_user, ...)), (dest_DSU (dest_user, ...)) 
may be present. For example, a flat destination list might contain 
(DSU_A USER_1), (DSU_A USER_2), (DSU_A), (DSU_B USER_3), (DSU_B USER_4) 
whereas a factored destination list would contain 


(DSU_A (USER_1, USER_2)), (DSU_A), (DSU_B (USER_3, USER_4)). 


Dest 


Description: The destination associates dest_users with a dest_DSU. For flat destination 
lists, there are zero or one user names per dest. For factored destination 
lists, there can be multiple user names per dest. 


Dest_DSU 


Description: The destination_DSU is the name of one of the DSUs to which the distribution 
is to be sent. | 
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Dest_RGN 


Description: 


Format: 


Dest_REN 


Description: 


Format: 


Dest_User 


Description: 


Dest_DGN 
Description: 


Format: 


The destination RGN is the first part of a dest DSU name. This is typically, 
but not necessarily, the network ID. 


Character string 


CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) charac- 
ters are not allowed. 


The destination_REN is the second part of a dest_DSU name. This is typically, 
but not necessarily, the LU name. 


Character string 


CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


Note: If a product chooses to implement DGN=REN, the 
enhanced character set (ECS) subset is implemented in a 
particular network, and any DGN contains an ECS char- 
acter that is not an element of character set AR, then ECS 
characters may occur in this structure. 


The destination_user is the name of one of the users to which the distribution 
is to be sent. 


The destination_DGN is the first part of the name of a dest_user. 


Character string 


CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced character set) 
String Conventions: 
Base Leading, imbedded, and trailing space (X’40’) 


characters are not allowed. 


ECS Leading space (X’40’) characters are not 
allowed, trailing space characters are not sig- 
nificant, and imbedded space characters are 
significant. 
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Dest_DEN 


Description: The destination DEN is the second part of the name of a dest_user. 
Format: Character string 
CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced character set) 


String Conventions: 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. | 


ECS Leading space (X’40’) characters are not 
allowed, trailing space characters are not sig- 
nificant, and imbedded space characters are 
significant. 


Agent_Object 


Description: The agent_object is directly supplied by the origin agent. It is never parsed by 
the distribution service and is directly delivered, unchanged, to the agent at 
each destination. 


Format: Undefined byte string 
Server_Object 
Description: The server_object is identified by the origin agent and is fetched by the origin 


server when sending the dist_transport_MU. For FS1, the server_object is 
fetched by the origin server during transmission of the Dist_MU type TRANS- 
PorT. At each destination, the server_object is stored by the destination 
server and a notification of its receipt is delivered to the destination agent. 


Length Restriction: The maximum segment size for FS1 is 32511. 


Format: Undefined byte string 


Supplemental_Dist_Info2 


Description: The supplemental_dist_info2 structure is reserved for future use. 
Format: Undefined byte string 
DS _Suffix 
Description: The distribution_services_suffix contains no information and marks the end of 


the dist_transport_MU, dist_report_MU, or dist_continuation_MU. 
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Dist_Report_MU 


Description: The distribution_report_message_unit carries information reporting on the 
state of the distribution. Typically, for a multiple destination distribution, a 
dist report_MU will report on only a portion of the distribution. The report is 
delivered to the report-to destination if one was specified in the reported-on 
DTMU; otherwise, it is delivered to the distribution originator. 


Length Restriction: The minimum length of a dist_report_MU originated by an FS2 DSU is 78 
bytes. This is due to the length restriction on the Report_DTM. 


Report_Prefix 


Description: The report_prefix identifies the beginning of dist_report_MU. This structure 
carries information that changes from DSU to DSU. 


Report_Command 


Description: The report_command contains the control information for the distribution 
report. 


Length Restriction: The minimum length of a dist_report_MU originated by an FS2 DSU is 26 
bytes. This is due to the length restriction on the Report_DTM. 


Reporting_DSU 


Description: The reporting DSU is the name of the DSU that generated the report. 
Reporting _ RGN 
Description: The reporting_RGN is the first part of the name of the DSU that generated the 
report. This is typically, but not necessarily, the network ID. 
Format: Character string 
CGCSGID: 01134-00500 (character set AR) 


string Conventions: Leading, trailing, and imbedded space (X’40’) characters 
are not allowed. 


Reporting_REN 
Description: The reporting REN is the second part of the name of the DSU that generated 
the report. This is typically, but not necessarily, the LU name. 
Format: Character string 


CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, trailing, and imbedded space (X’40’) characters 
are not allowed. 
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Report_DTM 


Description: The report_date-time contains the date and time at which the reporting DSU 
generated the report. FS2 products support the offset from GMT for local 
time. 


Length Restriction: Originating FS2 DSUs always generate a GMT-based time. The minimum 
length for report_DTM is therefore 11 (1-origin). 


Format: Byte string 
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Byte Content 


0-1 LT header 
DATE 
2-3 Year, in binary (e.g., 1989 is encoded as X’07C5’) 
4 Month of the year, in binary (values from 1 to 12 are valid) 
5 Day of the month, in binary (values from 1 to 31 are valid) 
TIME 
6 Hour of the day, in binary (values from 0 to 23 are valid) 
7 Minute of the hour, in binary (values from 0 to 59 are valid) 
8 Second of the minute, in binary (values from 0 to 59 are valid) 
) Hundredth of the second, in binary (values from 0 to 99 are valid) 
GMT FLAGS 
10 Indicates that specified TIME is GMT and identifies whether offsets 
from GMT are required to calculate local time. (Equivalent EBCDIC 
characters are shown in parentheses.) 
X’E9’ (Zz) no offset required 
X’4E’ (+) add required offset to GMT to get 
local time 
X60’ = {-) ~=— subtract required offset from GMT to get 
local time 
Note: All other values are reserved. 
11 Hour offset from GMT, in binary, occurs when GMT flag # X’E9’ 
(values from 0 to 23 are valid) 
12 Minute offset from GMT, in binary, occurs when GMT flag # X’E9’ 
(values from 0 to 59 are valid) 
Examples: 


A 9-byte date-time encoding is a date-time followed immediately by an EBCDIC 
“Z and is considered to be GMT. Thus, 12:00GMT on 2 January 1988 would be 


X'97C401020CQO0000E9! 
yyyyMMddHHmmsshhZ 


An 11-byte date-time encoding is a date-time followed immediately by an 
EBCDIC ”+” or ”-” and two 1-byte binary numbers, and is considered to be 
GMT and the offset from GMT to local time. Thus, 7:00am on 2 January 1988 in 
New York would be 12:00GMT - 5 hours, or 


X'07C401020C000000600500'! 
yyyyMMddHHmmsshh- HHmm 


Report-To_DSU_User 


Description: The report-to_DSU_user is the DSU or user to which the distribution report is 
being sent. 
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Report_Information 


Description: The report_information identifies the distribution (or portion thereof) being 
reported on. 


Reported-On_Origin_DSU 


Description: The reported-on_origin_DSU is the name of the DSU at which the distribution 
was originated. | 


Presence Rules: If reported-on_origin_DSU is present, and reported-on_origin_user is absent, 
then the distribution was originated by a DSU; if reported-on_origin_user is 
present and reported-on_DSU is absent, then the report either originated in or 
passed through an FS1 subnetwork. If both reported-on_origin_DSU and 
reported-on_origin_user are present, then the report is not going to the origi- 
nator of the distribution; if both reported-on_origin_DSU and reportea- 
on_origin_user are absent, then they default to report-to_DSU and, if 
applicable, report-to_user. 


Reported-On_Origin_RGN 


Description: The reported-on_origin_RGN is the first part of the DSU name at which the dis- ! 
tribution originated. This is typically, but not necessarily, the network ID. 
Format: Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, trailing, and imibedded space (X’40’) characters 
are not allowed. 


Reported-On_Origin_REN 


Description: The reported-on_origin_REN is the second part of the DSU name at which the 
distribution originated. This is typically, but not necessarily, the LU name. 
Format: Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, trailing, and imbedded space (X’40’) characters 
are not allowed. 
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Reported-On_Origin_User 


Description: 


Presence Rules: 


Description: 


Format: 


Reported-On_Origin_DGN 


The reported-on_origin_user is the name of the user that originated the dis- 
tribution. 


If reported-on_origin_DSU is present, and reported-on_origin_user is absent, 
then the distribution was originated by a DSU; if reported-on_origin_user is 
present and reported-on_DSU is absent, then the report either originated in or 
passed through an FS1 subnetwork. If both reported-on_origin DSU and 


reported-on_origin_user are present, then the report is not going to the origi- 
nator of the distribution; if both reported-on_origin_DSU and reported- 
on_origin_user are absent, then they default to report-to_DSU and, if 
applicable, report-to_user. 


The reported-on_origin_DGN is the first part of the name of the user that origi- 
nated the distribution. 


Character string 


CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced char set) 
String Conventions: 


Base Leading, trailing, and imbedded space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are disal- 
lowed, trailing space characters are not signif- 
icant, and imbedded space characters are 
significant. 


Reported-On_Origin_DEN 


Description: 


Format: 


The reported-on_origin_DEN is the second part of the name of the user that 
originated the distribution. 


Character string 


CGCSGIDs: 01134-00500 (base), 00930-00500 (enhanced char set) 
String Conventions: 
Base Leading, trailing, and imbedded space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are disal- 
lowed, trailing space characters are not signif- 
icant, and imbedded space characters are 
significant. 


Appendix G. Encodings 589 


Reported-On_Seqno_DTM 


Description: The reported-on_sequence_number/date-time, in combination with the origin 
agent, origin DSU, and origin user, is the unique identifier of the distribution. 
The origin agent, origin DSU, and origin user are specified in the appropriate 
reported-on or report-to structures. The sequence number is the number 
assigned to the distribution by the origin agent. For FS2, the number ranges 
from 1 to (2**31)-1. For FS1, the number ranges from 1 to 9999. Refer to 
Appendix D for migration details. The date-time is the date and time gener- 
ated at the origin of the distribution. FS2 products support the offset from 
GMT for local time. 


Length Restriction: Originating FS2 DSUs always generate a GMT-based time. The minimum 
length for reported-on_seqno_DTM is 15 (1-origin). 


Format: Byte string 
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Byte Content 


0-1 LT header 
SEQNO 
2-5 Signed binary integer limited to (2**31)-1 
DATE 
6-7 Year, in binary (e.g., 1989 is encoded as X’07C95’) 
8 Month of the year, in binary (values from 1 to 12 are valid) 
) Day of the month, in binary (values from 1 to 31 are valid) 
TIME 
10 Hour of the day, in binary (values from 0 to 23 are valid) 
11 Minute of the hour, in binary (values from 0 to 59 are valid) 
12 Second of the minute, in binary (values from 0 to 59 are valid) 
13 Hundredth of the second, in binary (values from 0 to 99 are valid) 
GMT FLAGS 
14 Indicates that specified TIME is GMT and identifies whether offsets 


from GMT are required to calculate local time. (Equivalent EBCDIC 
characters are shown in parentheses.) 
X’ES’ (z) no offset required 
X’4E’ (+) add required offset to GMT to get 
local time 
X’60’ ‘{-) ~=subtract required offset from GMT to get 
local time 
Note: All other values are reserved. 


15 Hour offset from GMT, in binary, occurs when GMT flag # X’E9’ 
(values from 0 to 23 are valid) 
16 Minute offset from GMT, in binary, occurs when GMT flag # X’E9’ 


(values from 0 to 59 are valid) 


Examples: 


A 9-byte date-time encoding is a date-time followed immediately by an EBCDIC 
”“Z” and is considered to be GMT. Thus, 12:00GMT on 2 January 1988 would be 


X'97C401020CO00000E9'! 
yyyyMMddHHmmsshhZ 


An 11-byte date-time encoding is a date-time followed immediately by an 
EBCDIC ”+” or ”-” and two 1-byte binary numbers, and is considered to be 
GMT and the offset from GMT to local time. Thus, 7:00am on 2 January 1988 in 
New York would be 12:00GMT - 5 hours, or 


X'07C401020C0000000600500 ' 
yyyyMMddHHmmsshh- HHmm 
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Reported-On_Supp_Dist_Info1 
Description: The reported-on_supp_dist_infof structure is reserved for future use. 


Format: Character string 


Reported-On_Agent_Correl 


Description: The reported-on_agent_correlation is a string that was supplied by the origin 
agent at the origin DSU. 


Format: Undefined byte string 


Reported-On_Origin_Agent 


Description: The reported-on_origin_agent is the name of the transaction program at the 
origin DSU that originated the distribution that is being reported on. 


Presence Rule: Occurs when report-to_agent is different from origin_agent. If third-party 
reporting has been requested and a report was generated in or flowed 
through an FS1 subnetwork, the reported-on_origin_agent structure is dis- 


carded. 
Format: Character string, except for first byte 
CGCSGID: 01134-00500 {character set AR) 


String Conventions: Leading, trailing, and imbedded space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 
Reported-On_Dest_Agent 
Description: The reported-on_destination_agent is the name of the transaction program at 
the destination DSU that was specified for the reported-on distribution. 
Presence Rule: Occurs when dest_agent was specified in the reported-on DTMU. 
Format: Character string, except for first byte 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, trailing, and imbedded space (X’40’) characters 
are not allowed. 


The first byte of an SNA-registered transaction program 
name ranges in value from X’00’ to X’3F’. When the first 
byte ranges in value from X’41’ to X’FF’, the transaction 
program is not SNA registered. X’40’ is not a valid first 


byte. 
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Reported-On_Supp_Dist_Info2 
Description: The reported-on_supp_dist_info2 structure is reserved for future use. 


Format: Undefined byte string 


Dist_Continuation_MU 


Description: The distribution_continuation_message_unit is used by a sending DSU to con- 
tinue transmission of a suspended MU. 


Continuation_Prefix 


Description: The continuation_prefix identifies the beginning of a DCMU. 


Restarting_Byte_Position 


Description: The restarting _byte_position indicates where the sender is beginning 
retransmission of the first structure being re-sent. The byte count begins with 
the first byte of atomic data (i.e., no LLs included) within the encompassing 
structure. Absence of this structure is equivalent to the presence of a 1 in this 
structure, implying that the first structure present in the DCMU is being 
re-sent in its entirety. 0 is not allowed. 


Format: Unsigned binary integer (1-origin) 


SNA_Condition_Report 


Description: The SNA_condition_report describes the condition being reported. The condi- 
tion is always identified by an SNA_report_code. 


Certain conditions can be more fully described by supplementary information. 
Conditions pertaining to one or more structures in a format can have the 
location and contents of each of those structures specified by a 
structure_report. Certain conditions arise from inconsistencies among mul- 
tiple portions of the MU. Each portion is described by a separate 
structure_report. 
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SNA_Report_Code 


Description: The SNA_report_code is an SNA registered code identifying the condition that 
is being reported. Refer to Appendix E for allowable values and descriptions. 
Format: Byte string 
Byte Content 
0-1 LT header 
2-3 Primary report code 
4-5 Subcode 
Structure_Report 
Description: The structure_report reports on a structure involved in a format-related condi- 


tion. Depending on the condition, the structure_report may describe a struc- 
ture that was present in, or absent from, the reported-on MU. 


A format condition has its location in the MU pinpointed by a structure_spec 
and a list of parent_specs that define a line-of-descent. The line-of-descent 
begins with the MU and continues down the parent-child hierarchy to a level 
as low as the particular condition warrants. A registered ID always appears 
in a structure_report; if the reported-on structure is not itself a registered ID, 
its line-of-descent is traced up to include a registered ancestor. 


Presence Rule: Presence governed by the SNA_report_code. 


Structure_State 


Description: The structure_state indicates whether the reported-on structure was present 
or absent. 
Format: Hexadecimal code 
Byte Content 
0-1 LT header 
2 X’01° = STRUCTURE_PRESENT 


X’02’ + STRUCTURE_ABSENT 
Note: All other values are reserved. 
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Structure_Contents 


Description: 


Presence Rule: 


Format: 


Parent_Spec 


Description: 


Parent_ID_Or_T 


Description: 


Format: 


Parent_Class 
Description: 
Presence Rule: 


Format: 


The structure_contents is the portion of the MU that is relevant to the detected 
condition. Typically, the sfructure_contents contains the header of the struc- 
ture and at least the beginning of its contents. When the condition can be 
isolated to a portion of the structure, the structure_contents contains only that 
portion of the structure relevant to the condition. In this case, the 
structure_segment_number and structure_byte_offset locate the portion of the 
structure relevant to the condition. 


Allowed only when structure_state = STRUCTURE_PRESENT. 


Undefined byte string 


The parent_specification contains the identifier (ID or T) and the class of a 
parent structure. For a parent structure that occurs multiple times, the 
instance may also be included. The value of the parent_instance identifies the 
particular instance. The position of this parent structure within its parent {if 
one exists) may also be included. This would typically be done when this 
parent structure is an unordered child of its parent. 


The parent_ID_or_T is the ID or T value of a parent structure. ID values are 
the registered GDS codepoints. T values are architecture-specific values rela- 
tive to the encompassing ID. 


Undefined byte string 


The parent_class is the class of a parent structure. 
If absent, defaults to LENGTH-BOUNDED_LT_ STRUCTURE. 


Hexadecimal code 


Byte Content 
0-1 LT header 
2 X’01’ LENGTH-BOUNDED_LLID_STRUCTURE (ID) 
X’02’ LENGTH-BOUNDED_LT_STRUCTURE (T) (default) 
X’03° DELIMITED_LLID_ STRUCTURE (DEL-ID) 
X’04’ DELIMITED_LT_STRUCTURE (DEL-T)’ 
X’05" IMPLIED_LLID_ STRUCTURE (IMP-ID) 
X’06’ IMPLIED_LT_STRUCTURE (IMP-T) 


Note: All other values are reserved. 
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Parent_Position 


Description: The parent_position is the position of this parent structure within its parent (if 
one exists) in this particular MU. Multiple consecutive instances of a repeat- 
able parent structure share a single position, and can be distinguished by 
parent_instance. 


Format: Signed binary integer 
Parent_Instance 
Description: The parent_instance is used when a parent structure occurs multiple times. 
The value of parent_instance identifies the particular instance within a posi- 
tion. 
Format: Signed binary integer 
Structure_Spec 
Description: The structure_specification contains the identifier (ID or T) and the class of a 


structure. For a structure that occurs multiple times, the instance may also be 
included. The value of the structure_instance identifies the particular 
instance. The position of this structure within its parent structure may also be 
included. This would typically be done when the parent structure contains 
unordered children. 


Presence Rule: Absent only when the structure_ciass is the default and the sibling_list con- 
tains all pertinent ID or T values. 


Structure_ID_Or_T 


Description: The structure_/D_or_T is the ID or T value of the structure. ID values are the 
registered GDS codepoints. T values are architecture-specific values relative 
to the encompassing ID. 


Presence Rule: Required except when sibling _list contains all pertinent ID or T values. In this 
case, the structures specified by sibling_list are the structures being reported 
on. 

Format: Undefined byte string 
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Structure_Class 


Description: 


Presence Rule: 


Format: 


The structure_class is the class of the reported-on structure and any siblings 
identified in sibling_list. 


lf absent, defaults to LENGTH-BOUNDED_LT_STRUCTURE. 


Hexadecimal code 


Byte Content 
0-1 LT header 
2 X’01’ LENGTH-BOUNDED LLID STRUCTURE (ID) 
X’02’ LENGTH-BOUNDED_LT_STRUCTURE (T) (default) 
X03’ DELIMITED _LLID_ STRUCTURE (DEL-ID) 
X’04’ DELIMITED_LT_STRUCTURE (DEL-T) 
X’05’ IMPLIED_LLID_ STRUCTURE (IMP-ID) 
X’06’ IMPLIED_LT_STRUCTURE (IMP-T) 


Note: All other values are reserved. 


Structure_Position 


Description: 


Format: 


The structure_position is either the actual or expected position of this struc- 
ture within its parent in this particular MU. Multiple consecutive instances of 
a repeatable structure share a single position, and can be distinguished by 
structure_instance. 


Signed binary integer (1-origin) 


Structure_Instance 


Description: 


Format: 


The structure_instance is used when the structure is one of multiple occur- 
rences of a repeatable structure. The value of structure_instance identifies 
the particular instance within a position. 


Signed binary integer (1-origin) 


Structure_Segment_Number 


Description: 


Presence Rule: 


Format: 


The structure_segment_number is the segment of the structure in which the 
condition was detected. 


Occurs when the beginning of structure_contents was not contained in the first 
segment of the reported-on structure. 


Signed binary integer (1-origin) 
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Structure_Byte_Offset 


Description: The structure_byte_offset marks the start of structure_contents within the 
reported-on structure. If structure_segment_number is present, this value is 
the offset from the start of the indicated segment; otherwise, it is the offset 
from the beginning of the structure. 


Format: Signed binary integer (0-origin) 


Sibling_List 


Description: The sibling_list contains a string of ID or T values necessary to describe the 
detected condition. The structures identified in sibling list are children of the 
parent identified in parent_spec and/or siblings of the structure identified in 
structure_spec. The class of the sibling structures is the same as 
structure_ciass. The expected position, when applicable, is given by 


structure_position. 
Presence Rule: Presence is governed by the SNA_report_code. 
Format: Byte string 


Reported-On_Dest_List 


Description: The reported-on_destination_list contains the portion of the distribution desti- 
nations that are being reported on. 


Presence Rule: Presence is governed by the SNA_report_code. 


Reported-On_Dest_Prefix 


Description: The reported-on_destination_prefix is the prefix of the reported- 
on_destination_list. 


Reported-On_Dest 


Description: The reported-on_destination associates reported-on_dest_users with a 
reported-on_dest_DSU for those cestinations specified in the original distrib- 
ution request being reported on. For flat destination lists (i.e., lists containing 
only DSUs and/or DSU-user pairs), there are zero or one user names per DSU 
list. For factored destination lists, there can be multiple user names per DSU 
list. 


Reported-On_Dest_DSU 


Description: The reported-on_destination_DSU is one of the original destination DSUs 
being reported on. 
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Reported-On_Dest_RGN 


Description: The reported-on_destination_RGN is the first part of the name of one of the 
original destination DSUs being reported on. This is typically, but not neces- 
sarily, the network ID. 


Presence Rule: Absent when passed through an FS1 subnetwork. 
Format: Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


Reported-On_Dest_REN 


Description: The reported-on_destination_REN is the second part of the name of one of the 
original destination DSUs being reported on. This is typically, but not neces- 
sarily, the LU name. 


Presence Rule: Absent when passed through an FS1 subnetwork. 
Format: Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


Note: If a product chooses to implement DGN =REN, the ECS 
subset is implemented in a particular network, and any 
DGN contains an ECS character that is not an element of 
Character Set AR, then ECS characters may occur in this 
structure. 


Reported-On_Dest_User 


Description: The reported-on_destination_user is the name of one of the original destina- 
tion users being reported on. 
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Reported-On_Dest_DGN 


Description: The reported-on_destination_DGN is the first part of the name of one of the 
original destination users being reported on. 

Note: In FS1, for a DS condition code of X’000D’ (lost user names), user names will 
be null. 

Format: Character string 
CGCSGID: 01134-00500 (base), 00930-00500 (enhanced character set) 


String Conventions: 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are not allowed, 
trailing space characters are not significant, and 
imbedded space characters are significant. 


Reported-On_Dest_DEN 


Description: The reported-on_destination_DEN is the second part of the name of one of the 
original destination users being reported on. 

Note: In FS1, for a DS condition code of X’000D’ (lost user names), user names will 
be null. 

Format: Character string 
CGCSGID: 01134-00500 (base), 00930-00500 (enhanced character set) 


String Conventions: 


Base Leading, imbedded, and trailing space (X’40’) 
characters are not allowed. 


ECS Leading space (X’40’) characters are not allowed, 
trailing space characters are not significant, and 
imbedded space characters are significant. 


Reported-On_Dest_Suffix 


Description: The reported-on_ destination _suffix is the suffix of the reported- 
on_destination_list. 


Supplemental_Report 


Description: The supplemental_report contains other information pertaining to a condition. 
The contents of the supplemental_report are governed by the 
SNA_report_code. 


Presence Rule: Presence is governed by the SNA_report_code. 
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Sender_Exception_MU 


Description: The sender_exception_MuU is sent from the sender to the receiver when the 
sender detects an exception while sending a dist_transport_ MU, a 
dist_report_MU, or a dist_continuation_MU. 


Receiver_Exception_MU 


Description: The receiver_exception_MuU is sent from the receiver to the sender when the 
receiver detects an exception while receiving a dist_transport_MU, a 
dist_report_MU, or a dist_continuation_MU. 


Receiver_Exception_Command 


Description: The receiver_exception_command is the prefix identifying the 
receiver_exception_MU. 


Sender_Retry_Action 
Description: The sender_retry_action is the receiver’s recommendation to the sender as to 
whether to retry the transmission of the MU. 
Format: Hexadecimal code 
Byte Content 
0-1 LT header 
2 X’01’ RETRY_PRECLUDED 
X’02’ RETRY_ALLOWED 
X’03’ RETRY_EXPECTED_USING_DCMU 


Note: All other values are reserved. 


Receiving _ DSU 
Description: The receiving_DSU is the name of the DSU to which a distribution was being 
sent. | 
Receiving RGN 
Description: The receiving_RGN is the first part of the name of the DSU to which a distrib- 
ution was being sent. This is typically, but not necessarily, the network ID. 
Format: Character string 


CGCSGID: : 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 
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Receiving _REN 


Description: The receiving_REN is the second part of the name of the DSU to which a dis- 
tribution was being sent. This is typically, but not necessarily, the LU name. 
Format: Character string 
CGCSGID: 01134-00500 (character set AR) 


String Conventions: Leading, imbedded, and trailing space (X’40’) characters 
are not allowed. 


Note: — If a product chooses to implement DGN=REN, the 
enhanced character set (ECS) subset is implemented in a 
particular network, and any DGN contains an ECS char- 
acter that is not an element of SNA Character Set AR, 
then ECS characters may occur in this structure. 


Completion_Query_MU 


Description: The completion_query_message_unit is sent by the sending DSU to query the 
completion status of a particular MU at the receiving DSU. 


Completion_Report_MU 
Description: The completion_report_message_unit is sent by the receiving DSU to report on 
the completion status of a particular MU or to control traffic flow on a conver- 
sation. 


Indicator_Flags 


Description: The indicator_flags structure contains a 1-byte flag, to indicate the completion 
status of the MU_ID identified in a completion_report_MU, or to control traffic 
flow on a conversation. 


Format: Bit string 

Note: Conversation control flags (bits 2 and 3) may be used in conjunction with flow 
control flags (Not Received, In Transit, Suspended, Terminated, Completed, 
Purged). | 


Bit Map Architecturally-Defined 
01234567 wae 


Not Received 
In Transit 
Suspended 
Completed 
Terminated 
Purged 
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Last_Structure_Received 


Description: Last_structure_received is the codepoint of the structure the receiving DSU 
identifies as the last structure received before the MU was suspended. This 
structure must be a length-bounded LLID structure at the highest level of the 


MU. 
Presence Rule: If indicator_flags = SUSPENDED, then /ast_structure_received is present. 
Format: Hexadecimal code 


Last_Byte_Received 


Description: Last byte _received is the last byte received by the receiving DSU before the 
MU was suspended. The byte count begins with the first byte of atomic data 
within the encompassing structure. A byte count of X’FFFFFFFFFFFFFFFF’ indi- 
cates that the structure was fully received. The byte count contains only 
atomic data and does not contain the segmenting LLs for segmented struc- 


tures. 
Presence Rules: If indicator_flags = SUSPENDED, /ast_structure_received is present, and 
last_byte_received is absent, then the structure was received. 
Format: Unsigned binary integer (1-origin) 
Purge_Report_MU 
Description: The purge_report_message_unit indicates to the receiving DSU that the 


sending DSU has marked a particular MU_ID PURGED, and that the receiving 
DSU may flag that WU_ID as PURGED. 


Reset_Request_MU 


Description: The reset_request_message_unit is sent from DS_Send to DS_Receive. 
DS_Send issues the reset_request_MU to request that DS_Receive reset its 
MU_ID registry. 


Reset_DTM 


Description: The reset_date-time contains the date and time at which the reset_request_MU 
was generated. Both sender and receiver store it as the "time of last reset” of 
their MU_ID registries. | 


Length Restriction: Originating FS2 DSUs always generates a GMT-based time. The minimum 
| length for reset_DTM is 11 (1-origin). 


Format: Byte string 
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co oO NI OO 


11 


12 


Examples: 


_ Content 


LT header 


DATE 

Year, in binary (e.g., 1989 is encoded as X’07C5’) 

Month of the year, in binary (values from 1 to 12 are valid) 
Day of the month, in binary (values from 1 to 31 are valid) 


TIME 

Hour of the day, in binary (values from 0 to 23 are valid) 

Minute of the hour, in binary (values from 0 to 59 are valid) 
Second of the minute, in binary (values from 0 to 59 are valid) 
Hundredth of the second, in binary (values from 0 to 99 are valid) 


GMT FLAGS 
Indicates that specified TIME is GMT and identifies whether offsets 
from GMT are required to calculate local time. (Equivalent EBCDIC 
characters are shown in parentheses.) 
X’E9’ (Zz) no offset required 
X’4E’ (+) add required offset to GMT to get 
local time 
X’60’ (-) subtract required offset from GMT to get 
local time 
Note: All other values are reserved. 


Hour offset from GMT, in binary, occurs when GMT flag # X’E9’ 
{values from 0 to 23 are valid) 

Minute offset from GMT, in binary, occurs when GMT flag # X’E9’ 
(values from 0 to 59 are valid) 


A 9-byte date-time encoding is a date-time followed immediately by an EBCDIC 
"Z” and is considered to be GMT. Thus, 12:00GMT on 2 January 1988 would be 


X'07C401020COQO000E9! 
yyyyMMddHHmmsshhZ 


An 11-byte date-time encoding is a date-time followed immediately by an 
EBCDIC ”+” or ”-” and two 1-byte binary numbers, and is considered to be 
GMT and the offset from GMT to local time. Thus, 7:00am on 2 January 1988 in 
New York would be 12:00GMT - 5 hours, or 


Reset_Accepted_MU 


X'07C401020C000000600500 ! 
yyyyMMddHHmmsshh- HHmm 


Description: The reset_accepted_message_unit is sent from DS_Receive to DS_Send. 
DS_Receive issues the reset_accepted_MU in response to a reset_request_MU 
to inform DS_Send that DS_Receive has reset its MU_ID Registry. 
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Unrecognized_Reserve 


Description: The unrecognized_reserve is the number of bytes reserved for unrecognized 
structures. An unrecognized structure occurs within its parent structure. 
The number of unrecognized structures allowable for a particular parent 
structure is limited by the number of children allowable for that parent 
structure. 


Intermediate FS2 DSUs pass unrecognized_reserve structures through 
unchanged in outgoing DMUs. 


Format: Undefined byte string 
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Header Description Tables for FS1 Message Units 


DISTRIBUTION MESSAGE UNIT (DIST_MU) | 


Table 80 (Page 1 of 2). Distribution Message Unit (DIST_MU) 


Struct 
Structure Name Ref Pg Ee) IDF/T 


Dist_MU Del-IDF | pfx >148 
Prefix IDF/pfx | C00102 | 5-21 
Dist_Command IDF/seg |C10502 | 138-32511 

Service_Desc_Operands 58-774 

Dist_ID 28-107 

Origin RGN 3-10 
Origin _REN 3-10 
Origin_DGN 2-10 
Origin_DEN 2-10 
Origin_Seqno | 
Origin_DTM 
Agent_Correl 


Dist_Gen_Options 
Dist_Flags (FS1) 
Hop Count 
Service _Parms 
Server_Object_Ind 
Origin_Agent 

Report-To_Address 
Report-To_RGN 
Report-To_REN 
Report-To_DGN 
Report-To_DEN 

Report-To_Options 
Report_Service_Parms 
Report-To_Agent 

Agent_Object 


Destination_Operands Imp-IDF | t 


Begin_Dest_Operands IDF/idc 
Dest_RGN_List Imp-IDF | i 
-— Dest_RGN IDF/idc 
Begin_REN_ List IDF 
Dest_REN List Imp-IDF | i 
Dest_REN IDF/idc 
Begin_DGN_List IDF 
Dest_DGN_List Del-IDF 


v-- NV 


on 


IV on. ood 
ons 
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Table 80 (Page 2 of 2). Distribution Message Unit (DIST_MU) 


Struct Struct Occur- | Children 
NII les a ol ‘a 
able 


Dest_DGN 
Begin_DEN List 
Dest_DEN 
End_DEN_List 
End_DGN List 
End_REN_List 
End_Dest_Operands 
Dist_Report_Operands 


Dist_Server_Operands 


Server_Prefix 
Server_Obj_ Byte_Count 


Server 


Server_Parms 
Server_Object 
DS_ Suffix (FS1) 
Note: 


¢ * Refer to FS1 Structure Descriptions starting on page 610 for presence rules and length restrictions. 


¢ Dist_Report_Operands does not occur for Dist_MU type TRANSPORT. 


¢ Agent_Correl, Report-To_Address, Report-To_Options, Agent_Object, and Dist_Server_Operands do not occur 
for Dist_MU type REPORT. 


¢ Dest_RGN_List, Dest_REN_List, Dest_DGN_List, and Dest_DEN occur only one time for Dist_MU type REPORT. 
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DIST REPORT OPERANDS | 


|Table 81. Distribution Report Operands _ 


Struct 
Ref Pg 
616 


Structure Name 


Dist_Report_Operands 
Report_Operands 
Report_Correlation 
Reported-On_Origin_DGN 
Reported-On_Origin_DEN 
Reported-On_Seqno 
Reported-On_DTM 


Reported-On_Agent_Correl 


Receiving_DSU 
Receiving RGN 
Receiving_REN 
Gen_SNADS_ Report 
Gen_SNADS_Type 
Gen_SNADS_Contents 
Gen_SNADS_Cond_Code 
Gen_DIA_Report 
Gen_DIA_Type 
Gen_DIA_Contents 
Specific_Report 
Begin_Report_DGN List 
Report_DGN_List 
Reported-On_Dest_DGN 
Begin_Report_DEN_List 
Report_DEN_List 
Reported-On_Dest_DEN 
Spec_SNADS_Report 
Spec_SNADS_Type 
Spec_SNADS_Cont 
Spec_SNADS_CC 
Spec_DIA_Report 
Spec_DIA_Type 
Spec_DIA_Contents 
End_Report_DEN_List 
End_Report_DGN_List 


|Note: * Refer to FS1 Structure Descriptions starting on page 610 for presence rules and length restrictions. 
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Imp-IDF | i 


IDF/idc 
IDF 
7 


Imp-IDF | i 


IDF/ide 
IDF 
Imp-IDF 
IDF/idc 
Imp-IDF 


| IDF/ide 


IDF 
Imp-IDF 
IDF/idc 
Imp-IDF 
IDF/idc 


C35601 
C35741 
idc 
C35001 
idc 
C35401 
C35001 
idc 
C35501 
idc 
C35601 
C35741 


263 


“1 


wm ©) 
! 
at 
* 


1 
1 
1 
=i 


IV occa wd, 


i 
rences u 
nrc Order| Num | 54 
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SENDER EXCEPTION MESSAGE UNIT (TYPE FS1) 


Table 82. Sender Exception Message Unit (type FS1) 


Struct Struct Occur- 


[Sender_Exception MU (FS1) __|623_ DF |crozoi |g 1 


RECEIVER EXCEPTION MESSAGE UNIT (TYPE FS‘) 


Table 83. Receiver Exception Message Unit (type FS1) 


Structure Name Struct IDF/T Length Occur- 
Ref Pg rences 
601 pfx 


Receiver_Exception_MU (FS1) Del-IDF 
IDF/pfx | C00102 
IDF C10101 


Prefix 


Receiver_Exception_ Command 


Receiver_Exception_Correl IDF C32801 
Exception_And_Reply_Data Imp-IDF | idc 
Receiver_Exception_Code IDF/ide | C32201 


C34501 
C36141 


Reply Data 


Receiving_DSU 
Receiving RGN 
Receiving_REN 

SNADS_Report 
SNADS_Report_Type 
SNADS_Report_Cont 

SNADS_Report_CC 

DIA_Report 
DIA_Report_Type 
DIA_Report_Cont 

DS_Suffix (FS1) 


IDF/sfx | CFO100 
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FS1 Structure Descriptions 


Dist_MU 


Description: 


Prefix 


Description: 


Format: 


Dist_Command 


Description: 


The distribution_message_unit transports user information to one or more dis- 
tribution service users. A Dist_MU can be one of two types based on the 
value of dist_flags (type FS1): TRANSPORT or REPORT. A Dist_MU type TRANS- 
PORT transports agent and/or server objects. A Dist_MU type REPORT trans- 
ports information reporting on the state of the distribution. 


The prefix identifies the beginning of a message unit and may contain a 
message-unit identifier. 


Undefined byte string 


The distribution_command contains all information used by each DSU to trans- 
port the distribution for a Dist_MU fype TRANSPORT. For a Dist_MU type 
REPORT, the distribution_command contains the control information for the dis- 
tribution report. 


Service_Desc_Operands 


Description: 


Dist_ID 


Description: 


The service_description_operands contain all the information, except for the © 
destination list, required by each DSU to transport the distribution. 


The distribution_identifier contains information corresponding to the distrib- 
ution originator. 
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Origin_Seqno 


Description: The origin _sequence_number is the number assigned to the distribution by the 
origin_DSU. The value ranges from 1 to 9999 for a Dist_MU type TRANSPORT, 
and is always O for a Dist_MU fype REPORT. 


Format: Character string; each character is the EBCDIC representation of one digit of 
the sequence number. 


Byte Content 

0-1 LT header 

2-5 Sequence number 
Notes: 


e For Dist_MU type TRANSPORT, values range from X’FOFOFOF1’ to X’FSFOF9FY’. 
¢ For Dist_MU type REPORT, value is X’FOFOFOFO”. 


Origin_DTM 

Description: The origin_date-time is the date and time the distribution was originated by 
the origin DSU. Time is assumed to be local. 

Format: Byte string 
Byte Content 
0-1 LT header 

DATE 
2-3 Year, in binary (e.g., 1989 is encoded as X’07C5’) 
4 Month of the year, in binary (values from 1 to 12 are valid) 
5 Day of the month, in binary (values from 1 to 31 are valid) 
TIME 
6 Hour of the day, in binary (values from 0 to 23 are valid) 
7 Minute of the hour, in binary (values from 0 to 59 are valid) 
8 Second of the minute, in binary (values from 0 to 59 are valid) 
9 Hundredth of the second, in binary (values from 0 to 99 are valid) 
Example: 
The date-time encoding for 12:00 noon on 2 January 1988 is: 
X'97C401020C000000' 
yyyyMMddHHmmss hh 
Dist_Gen_Options 
Description: The distribution_general_options contains structures used by DS to condition 


its processing of the distribution. 
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Dist_Flags (type FS1) 


Description: The distribution_flags indicate reporting services requested by the origin 
agent. 

Format: 
Bit Content 
0 Exception Report bit: 


1 Distribution Message Unit type bit: 
O Distribution is of type TRANSPORT. 
1 Distribution is of type REPORT. 
2-/ Reserved 
Byte Content 
0-1 LT header 
2 X’00’ Dist_MU type TRANSPORT with report requested 
X’80’  Dist_MU type TRANSPORT with no report requested 
X’CO’ Dist_MU type REPORT with no report requested 
Note: All other values are reserved. 
Server_Object_Ind 
Description: The server_object_indicator indicates whether a server_object is present or 
not. The only values supported are 0 and 1. 
Presence Rule: Contains X’0001’ only for Dist_MU type TRANSPORT. 
Format: Hexadecimal code 
Byte Content 
0-4 LT header 
2-3 X’0000’ no server_object present in this MU 


Report-To_Address 


Description: The report-to_address contains the name of the DSU and user to which any 


0 DS is requested to generate a report in case 
of an exception. 

1 A-report will not be generated by DS for this 
distribution. 


X’0001’ a server_object present in this MU 
Note: All other values are reserved. 


distribution reports are sent. 


Presence Rule: —s This information may be present only in Dist_MU type TRANSPORT. 
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Report-To_Options 


Description: The report-to_options contains information involved in processing any reports 
generated as part of the distribution. 


Presence Rule: This information may be present only in Dist_MU type TRANSPORT. 


Destination_Operands 


Description: The destination _operands are the list of destinations for the distribution. Up to 
256 destinations are allowed if the distribution is of type TRANSPORT; exactly 
one destination, if the distribution is of type REPORT. The destinations are 
encoded as a fully factored, partially factored, or unfactored list of users and 
DSUs (see the following example). 


Exampie: The following is a list of destinations (qualified by RGN.REN.DGN.DEN): 
A.K.DA.U1, A.K.DA.U2, A.K.DB.U3, A.K.DB.U4, 
A.L.DC.U5, A.L.DC.U6, A.L.DD.U7, A.L.DD.U8, 
B.M.DE.U9, B.M.DE.U10, B.M.DF.U11, B.M.DF.U12, 
B.N.DG.U13, B.N.DG.U14, B.N.DH.U15, and B.N.DH.U16. 
The list may appear factored in destination_operands as follows: 


e Fully factored: 
A(K(DA(U1 


U8))) 
B(M(DE(U 
U10) 
DF(U11 
U12)) 
N(DG(U13 
U14) 
DH(U15 
U16)))) 


e Partially factored: 
(A(K(DA(U1) 


B(M(DE(US 
U10) 
DF(U11 
U12)) 
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N(DG(U13)) 

N(DG(U14)) 

N(DH(U15 
U16)))) 


e Unfactored, equivalent to the initial list: 
(A(K(DA(U1))) 
A(K(DA(U2))) 
A(K(DB(U3))) 
A(K(DB(U4))) 
A(L(DC(U5))) 
A(L(DC(U6))) 
A(L(DD(U7))) 
A(L(DD(U8))) 
B(M(DE(U9))) 
B(M(DE(U10))) 
B(M(DF(U11))) 
B(M(DF(U12))) 
B(N(DG(U13))) 
B(N(DG(U14))) 
B(N(DH(U15))) 
B(N(DH(U16)))) 


In the above lists, "(” represents begin_dest_operands, begin_REN_list, begin_DGN_list, or 
begin_DEN list. ”)” represents end_DEN_list, end_DGN_list, end_REN_list, or end_dest_operands. 
(Inner parentheses have precedence over outer parentheses.) 


Begin_Dest_Operands 


Description: The beginning_of_the_destination_operands marks the beginning of the 
destination_list. 
Format: Constant byte string; value is X’C35201’ 


Dest_RGN_List 


Description: The destination_RGN_list associates one destination RGN with at least one 
destination REN. 


Begin_REN_List 


Description: The beginning_of the_destination_REN_list marks the beginning of a list of one 
or more dest_REN({s). 
Format: Constant byte string; value is X’C35301’ 


Dest_REN_List 


Description: The destination_REN_list associates one destination REN with at least one 
destination DGN. 
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Begin_DGN_List 


Description: The beginning_of_the_destination DGN_list marks the beginning of a list of 
one or more dest_DGN(s). 
Format: Constant byte string; value is X’C35401’ 
Dest_DGN_List 
Description: The destination _DGN_list associates one dest_DGN with at least one 
dest DEN. 


Begin_DEN_List 


Description: The beginning_of_the_destination_DEN_list marks the beginning of a list of one 
or more dest_DEN(s). 
Format: Constant byte string; value is X’C35501’ 


End_DEN_List 


Description: The end_destination_DEN_list marks the end of the list begun by the corre- 
sponding begin_DEN list. 


End_DGN_List 


Description: The end_destination_DGN_list marks the end of the list begun by the corre- 
sponding begin_DGN_list. 


End_REN_List 


Description: The end_destination_REN_list marks the end of the list begun by the corre- 
sponding begin_REN list. 


End_Dest_Operands 


Description: The end_destination_operands marks the end of the destination_list. 


Dist_Server_Operands 


| Description: The distribution_server_operands structure contains the server_prefix and the 
server_object. 


Presence Rule: This information occurs only in Dist_MU type TRANSPORT when 
server_object_ind =X’0001’. 


Server_Prefix 


Description: The server_prefix contains information associated with the server_object. 
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Server_Parms 


Description: The server_parameters structure contains parameters passed by DS to the 
destination server. This structure is never sent, and is retired in FS2. 


Format: Undefined byte string 


DS_ Suffix (FS1) 


Description: The distribution_services_suffix contains no information and marks the end of 
the message unit. 


Dist_Report_Operands 


Description: The distribution_report_operands structure contains all the report information 
describing the condition of a particular distribution. 
Presence Rule: This information occurs only when Dist_MU is of type REPORT. 
Report_Operands 
Description: The report_operands structure contains all information pertaining to the origi- 


nator of the distribution and the detector of an exception. 


Report_Correlation 


Description: The report_correlation contains information that uniquely identifies a distrib- 
ution being reported on. 


Reported-On_Seqno 


Description: The reported-on_origin_sequence_number is the sequence number of the dis- 
tribution being reported on. 


Format: Character string; each character represents the EBCDIC representation of 
one digit of the sequence number. 


Byte Content 
0-1 LT header 
2-5 sequence number 


Note: Values range from X’FOFOFOF1’ to X’F9F9FSFY’. 


616  SNA/Distribution Services Reference 


Reported-On_DTM 


Description: The reported-on_date-time is the date and time the distribution was originated. 
Byte Content 
0-1 LT header 
DATE 
2-3 Year, in binary (e.g., 1989 is encoded as X’07C5’) 
4 Month of the year, in binary (values from 1 to 12 are valid) 
5 Day of the month, in binary (values from 1 to 31 are valid) 
TIME 
6 Hour of the day, in binary (values from 0 to 23 are valid) 
7 Minute of the hour, in binary (values from 0 to 59 are valid) 
8 Second of the minute, in binary (values from 0 to 59 are valid) 
g Hundredth of the second, in binary (values from 0 to 99 are valid) 


Example: 
The date-time encoding for 12:00 noon on 2 January 1988 is: 


X'07C401020C000000' 
yyyyMMddHHmmss hh 


_Gen_SNADS_Report 


Description: The general_ SNADS_report contains the DS report applicable to each user 
specified in specific_report for which a spec SNADS_report is not supplied. 


Note: Older DSUs may generate both gen_SNADS_report and gen_D/A_report ina 
single MU. All DSUs are able to receive such MUs. However, DSUs may 
ignore gen_D/A_report if gen_SNADS_report is present. A sending DSU never 
generates both a DIA report and a DS report for multiple destinations. 


Presence Rule: This information occurs when gen_SNADS _ type = X’0001’. 
Gen_SNADS_Type 
Description: The general SNADS_type indicates that a DS condition is being reported. 
Format: Hexadecimal code 
Byte Content 
0-4 LLIDF header 
5-6 X’0001’ DS report 


Note: Any other value indicates that this is not a 
gen_SNADS_report. 
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Gen_SNADS_Content 


The general_SNADS_contents contains information describing the condition 
being reported on. 


Description: 


Gen_SNADS_Cond_Code 


Description: The general SNADS_condition_code is the particular condition being reported 
on. 
Format: Hexadecimal code 


Gen_DIA_Report 


Byte Content 
0-1 LT header 
2-3 X’0001’ ~=—routing exception 
X’0002" ~unknown user name 
X’0003’ hop count exhausted 
X’0004’ format exception 
X’0005’ _~—s function not supported 
X’0006’ ~=—sspecific-server exception 
X’0007’ unknown resource name (specific server) 
X’0008’ ~=invalid server parameters 
X’0009" ~=sunknown resource name (destination agent) 
X’000C’— operator intervention (purging) 
X’000D’ user names lost 
X’000E’ —iresource not available 
X’000F’ system exception 
X’0010’ ~—s insufficient resource 
X’0011’ = storage-medium exception 
X’0012’ = REMU exception 
X’0013’ ~—s server object size incompatible with capacity 


level 


Note: All other values are reserved. 


Description: The general_DIiA_report describes an application-layer condition. The 
gen_D/A_report applies to all users specified in specific_report. The inter- 
action between gen_D/A_report and spec_D/A_report is defined by DIA. 

Note: Older DSUs may generate both gen_SNADS_report and gen_D/A_report ina 


Presence Rule: 


single MU. All DSUs can receive such MUs. However, DSUs may ignore 
gen_DIiA_report if gen_SNADS_report is present. A sending DSU never gener- 
ates both a DIA report and a DS report for multiple destinations. 


This information occurs when gen_D/A_ftype # X’0001’. 
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Gen_DIA_Type 


Description: The general D/A_type indicates the type of DIA condition being reported. 
Format: Hexadecimal code 

Byte Content 

0-4 LLIDF header 

5-6 X’0001’ indicates this is not a gen_D/A_report 


X’0200" ~=—DIA application exceptions 
X’FEFF’ reserved for 5520 migration 
Note: All other values are reserved. 


Gen_DIA_Contents 


Description: The general_DIA_contents structure contains a DiA-defined byte string. 


Length Restriction: Older DSUs may generate MUs with length of up to 517. All DSUs receive 
such MUs without generating an exception. However, DSUs may modify such 
MUs to force the length to be 69 or less. For gen_DiA_type of X’0200’ (DIA 
application exceptions), the truncation algorithm is given in the DIA Trans- 
action Programmer's Guide. The length is at least 7, since gen_DIA_contents 
contains at least a null LT (an LT of length 2). 


Format: Undefined byte string 


Specific_Report 


Description: The specific_report contains the portion of the destination users that are being 
reported on. Any specific DS and/or DIA reports are also specified within this 
structure. 

Begin_Report_DGN _List 
Description: The beginning_of_report_DGN_list marks the beginning of the specific_report. 
Format: Constant byte string; value is X’C35401’ 


Report_DGN_List 


Description: The report_DGN_list associates one reported-on_dest_DGN with at least 
one reported-on_dest_DEN. 


Begin_Report_DEN_List 


Description: The beginning_of_report_DEN_list marks the beginning of a list of one or more 
reported-on_dest_DENs. 
Format: Constant byte string; value is X’C35501’ 
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- Report_DEN_List 


Description: The report_DEN_list associates one reported-on_dest_DEN with a specific DS 
and/or DIA report. 


Spec_SNADS_Report 


Description: | The specific_SNADS_report is a report on one particular user. This report 
overrides the gen_SNADS_report, if one exists, for that particular user. 


Note: Older DSUs may generate both spec_SNADS_report and spec_D/A_report ina 
single MU. All DSUs can receive such MUs. However, DSUs may ignore 
spec_DIA_report if spec_SNADS _report is present. A sending DSU never gen- 
erates both a DIA report and a DS report for multiple destinations. 


Presence Rule: This information occurs when spec_SNADS_ type = X’0001’. 


Spec_SNADS_Type 


Description: The specific_SNADS_type indicates that a DS condition is being reported. 
Format: Hexadecimal code 

Byte Content 

0-4 LLIDF header 

5-6 X’0001" DS report 


Note: Any other value indicates that this is not a 
spec_SNADS_report. 


Spec_SNADS_Cont 


Description: The specific_SNADS_contents contains information describing a condition 
being reported on. 
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Spec_SNADS_CC 


Description: 


Format: 


Spec_DIA_Report 


Description: 


Note: 


Presence Rule: 


The specific _SNADS_condition_code describes the particular condition being 
reported on. 


Hexadecimal code 


Byte Content 
0-1 LT header 
2-3 X’0001’ ~—s routing exception 
X’0002’ unknown user name 
X’0003’ hop count exhausted 
X’0004’ format exception 
X’0005’_—s function not supported 
X’0006’ = specific-server exception 
X’0007’ unknown resource name (specific server) 
X’0008’ invalid server parameters 
X’0009° +~unknown resource name (destination agent) 
X’000C’_— operator intervention (purging) 
X’000D’ user names lost 
X’000E’ resource not available 
X’000F’ system exception 
X’0010’ insufficient resource 
X’0011° = storage-medium exception 
X’0012’ REMU exception 
X’0013’ ~=server object size incompatible with capacity 


The specific_DiA_report describes a DlA-specific report on one particular 


level 


Note: All other values are reserved. 


user. 


Older DSUs may generate both spec SNADS_report and spec_D/IA_report in a 
single MU. All DSUs can receive such MUs. However, DSUs may ignore 
spec_DIA_report if spec_SNADS_report is present. A sending DSU never gen- 
erates both a DIA report and a DS report for multiple destinations. 


This information occurs when spec_D/A_ftype # X’0001’. 
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Spec_DIA_Type 


Description: The specific_DiA_type indicates the type of DIA condition being reported. 
Format: Hexadecimal code 

Byte Content 

0-4 LLIDF header 

5-6 X’0001’ ~—indicates this is not a spec_D/A_report 


X’0200’ DIA application exceptions 
X’FEFF’ reserved for 5520 migration 
Note: All other values are reserved. 
Spec_DIA_Contents 
Description: The specific_DiIA_contents structure contains a DlA-defined byte string. 


Length Restriction: Older DSUs may generate MUs with length of up to 517. All DSUs receive 
| such MUs without generating an exception. However, DSUs may modify such 
MUs to force the length to be 69 or less. For spec_D/A_type of X’0200’ (DIA 
application exceptions), the truncation algorithm is given in the DIA Trans- 
action Programmer’s Guide. The length is at least 7, since spec_D/A_contents 
contains at least a null LT (an LT of length 2). 


Format: Undefined byte string 


End_Report_DEN_List 


Description: The end_report_DEN_list marks the end of the list begun by 
begin_report_DEN_list. 


End_Report_DGN_List 
Description: The end_report_DGN_list marks the end of the specific_report. 
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Sender_Exception_MU (Type FS1) 


Description: 
Format: Byte string 
Byte Bit 
0-4 
3) 
0-1 
2-7 
6 
7 


The sender_exception_MuU (type FS1) is sent from the sender to the receiver 
when the sender detects an exception while sending a Dist_MU. 


Content 
LLIDF header 


Severity: 
11 catastrophic 


Class: 
000101 sender 


Exception condition code: 
X’06’ execution terminated 
X’0B’ I/O error 

X’OF’ length invalid 

x18’ content error 


Exception object: 

X’01’ IU prefix 

X07’ command 

X’0C’ document unit 

X’13” IU suffix 

X17’ unknown subfield 

X'1A’ distribution object prefix 
X’1B’ distribution object data 


Note: Other values and their corresponding meanings are represented under 
receiver_exception_code. 


Receiver_Exception_MU (Type FS‘) 


Description: 


Receiver_Exception_Command 


Description: 
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The receiver_exception MU (type FS1) is sent from the receiver to the sender 
when the receiver detects an exception while receiving a Dist_MU. 


The receiver_exception_command contains all information used for identifying 
the exception that occurred. 
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Receiver_Exception_Correl 


Description: The receiver_exception_correlation contains the prefix ID value from the 
rejected Dist_MU. 
Format: Byte string 
Byte Content 
0-4 LLIDF header 
5 Correlation field: 
X’00’ 
Note: All other values are reserved. 
6 Command sequence number: 
X’01’ 
Note: All other values are reserved. 
1-22 Correlation MU ID; value from the prefix of the Dist_MU 


Exception_And_Reply_Data 


Description: The exception_and_reply_data contains information pertaining to the exception 
causing the rejection of the Dist_MU. 
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Receiver_Exception_Code 


conditionally, the portion of the Dist_MU containing the exception. 


Description: 
Format: Byte string 
Byte Bit 
0-4 
5 
0-1 
2-/ 
6 
7 


Content 
LLIDF header 
Severity: 


11 catastrophic 
Note: All other values for bits 0-1 are reserved. 


Class: 
000010 = syntactic 
000011 semantic 


000100 process 
Note: All other values for bits 2-7 are reserved or 
defined elsewhere. 


Exception condition code 
(indicates reason for exception): 


x’01’ 
X’02’ 
x’04’ 
X’06’ 
x’07’ 
X’08’ 
X’0A’ 
X’0B’ 
X’0C’ 
X’0E’ 
X’OF’ 
X’40’ 
x11’ 
X15’ 
X16’ 
X17’ 
X48" 


function not supported 
data not supported 
resource not available 
execution terminated 
data not found 
segmentation 
sequence 

I/O error 

ID invalid 

format invalid 

length invalid 
indicator invalid 

range exceeded 
subfield length invalid 
subfield type invalid 
invalid parameters 
content error 


Note: All other values are reserved. 


Exception object 
(indicates the syntactical entity in error): 


X01’ 
X’02’ 
X07’ 
X’08’ 
X’09’ 
X’0C’ 
X’0D’ 


IU prefix 

IU identifier 

command 

command operand 
operand value 
document unit 
document unit identifier 
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Byte | Bit Content 
X’0E’ document profile 
X’OF’ document profile parameter 
X’10’ document content introducer 
x’11" document content control 
X’12’ document content data 
X’13" IU suffix 
X14’ segment 
X’16" unsupported subfield 
X17’ unknown subfield 
X'1A’ _ distribution object prefix 
X’1B’ distribution object data 
Note: All other values are reserved. 


8-254 Exception data 
contains the Dist_MU structures in error 
Reply_Data 
Description: The reply_data describes which DSU rejected the Dist_MU and why the 
Dist_MU was rejected. 
SNADS_Report 
Description: The SNADS_report contains information describing the particular DS exception 
that caused the Dist_MU to be rejected. 
SNADS_Report_Type 
Description: The SNADS_report_type indicates that a DS exception is being reported. 
Format: Hexadecimal code 


Byte Content 
0-4 LLIDF header 
5-6 X’0001’ DS report 


Note: Any other value indicates that this is not a SNADS_report. 


SNADS_Report_Cont 


Description: The SNADS_report_contents structure contains information describing the type 
of DS condition in the Dist_MU. 
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SNADS_Report_CC 


Description: 


Format: 


The SNADS_report_condition_code describes the particular DS condition that 
caused the Dist_MU to be rejected. 


Hexadecimal code 


Byte 


Content 


LT header 


X’0001’ 
X"0002" 
X’0003’ 
X’0004’ 
X’0005’ 
X*0006" 
X’0007’ 
X‘0008’ 
X’0009’ 
X‘000E’ 
X’O00F’ 
X’0010° 
X’0011’ 
X0013" 


routing exception 

unknown user name 

hop count exhausted 

format exception 

function not supported 

specific-server exception 

unknown resource name (specific server) 
invalid server parameters 

unknown resource name (destination agent) 
resource not available 

system exception 

insufficient resource 

storage-medium exception 

server object size incompatible with capacity 


level 
Note: All other values are reserved. 
DIA_Report 
Description: The D/A_report describes a DIA condition being reported. 


Note: When generating a Dist_MU type REPORT with report information supplied by a 
REMU (type FS1), the reporting DSU may ignore D/A_report. 


Presence Rule: This information occurs when gen_DIA_type # X’0001’. 
DIA_Report_Type 
Description: The DIA_report_type indicates the type of DIA condition being reported. 


Format: Hexadecimal code 


Byte Content 
0-4 LLIDF header 
5-6 X’0001’ indicates this is not a DIA_report 


X’‘0200’ DIA application exceptions 
X’FEFF’ reserved for 5520 migration 
Note: All other values are reserved. 
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DIA_Report_Cont 
Description: The DIA_report_contents structure contains a DlA-defined byte string. 


Format: Undefined byte string 
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Graphic Character Sets 1134 and 930 


Table 84 (Page 1 of 2). Graphic Character 
Sets 1134 and 930 


pee Description 


Space 


Period 

Ampersand 

Sharp s 

Dollar Sign 

Minus Sign 

Slash 

A Circumflex, Capital 
A Diaeresis, Capital 
A Grave, Capital 

A Acute, Capital 

A Tilde, Capital 

A Overcircle, Capital 
C Cedilla, Capital 

N Tilde, Capital 
Comma 

E Acute, Capital 

E Circumflex, Capital 
E Diaeresis, Capital 
E Grave, Capital 

| Acute, Capital 

| Circumflex, Capital 
| Diaeresis, Capital 
| Grave, Capital 
Number Sign 

At Sign 

Apostrophe 

O Slash, Capital 

a, Small 

b, Small 

c, Small 

d, Small 

e, Small 

f, Small 


x KK KK KKM KKM KKK KR KK KK KK KKK KKK KK KK 


g, Small 
h, Small 
i, Small 


s-7> eo ~~ O09 Qa 0O & & 


os 


om 
on 
wo 
4 


j, Small 


cae o 


Table 84 (Page 1 of 2). Graphic Character 
Sets 1134 and 930 

Hex ee | Set 

Code Description 1134] 930 


k, Small 

|, Small 

m, Small 

n, Small 

o, Small 

p, Small 

q, Small 

r, Small 

a Underscore, Small 
o Underscore, Small 
AE Dipthong, Capital 
Micro, Mu 

s, Small 

t, Small 

u, Small 


v, Small 
w, Small 
x, Small 
y, Small 
|z, Small 
D Stroke, Capital 
Y Acute, Capital 
Thorn, Capital 

A, Capital 

B, Capital 

C, Capital 

D, Capital 

E, Capital 

F, Capital 

G, Capital 

H, Capital 

|, Capital 

J, Capital 

K, Capital 

L, Capital 

M, Capital 

N, Capital 
O, Capital 


N< <* ¢ < © * ® 


xx xx “x -«e«e«ReK KKK KK 
xx «xx xKMMewReK KKK KKK KK 


Oz 2Fzrxe 7 TaTtmtmmoeaw >Yp 


Encodings 
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Table 84 (Page 2 of 2). Graphic Character 
Sets 1134 and 930 

Hex | set | 

Code Description 134] 930° 


P, Capital 

Q, Capital 

R, Capital 

y Diaeresis, Small 
S, Capital 

T, Capital 

U, Capital 

V, Capital 

W, Capital 

X, Capital 

Y, Capital 

Z, Capital 

O Circumflex, Capital 


N< xs < CHO 
<x<~«—x x x «x «KK 


O Diaeresis, Capital 
O Grave, Capital 

O Acute, Capital 

O Tilde, Capital 
Zero 
One 


Two 
Three 
Four 
Five 
Six 
Seven 
| Eight 

Nine 


OON DOA AR WOH = O 
x KKK KK KK KK 


U Circumflex, Capital 
U Diaeresis, Capital 
U Grave, Capital 

U Acute, Capital 


x «* «— KKK KK KK KK KK mK KK KKK KKK KKK KK KK OM 


Note: Character set A, CGCSGID (00961-00500), is a superset of 
character set 1134. Character set A also contains ’$” (X’5B’), “#” (X’7B’) 
and “@” (X’7C’). New DS implementations are able to receive 
structures using character set A. 


Character set AE, CGCSGID (01130-00500), is a superset of character 
set 1134. Character set AE also contains ”.” (X’4B’), ”$” (X’5B’), "#” 
(X’'7B’), “@” (X’7C’), and all lower-case alphabetics (a-z). 

New DS implementations are able to receive structures using character 
set AE. | 
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Transaction Program and Server Names 


Following is a list of all transaction program and server names defined for 


SNA/DS, in the FM header 5 (Attach), in the Distribution MU, or used internally 
in the distribution service unit (DSU). 


Code 

X’20FOFOFO’ 
X’20F OF OF 1’ 
X’20FOF OF 2’ 
X’21FOFOF1’ 
X’21FOFOF 2’ 
X’21FOFOF3’ 
X’21F OF OF6’ 
X’21FOFOF7’ 
X’21FOFOF8’ 
X’23FOFOFO’ 
X’24F OF OF 0’ 
X’30F OF OF 2’ 


X’30F OF OF 3” 


Meaning 

DIA process destination transaction program name 
DIA server name 

DIASTATUS transaction program name 

DS_SEND transaction program name (FS1) 

DS_ RECEIVE transaction program name (FS1) 

DS ROUTER_DIRECTOR transaction program name 
SNA/DS general server name 

DS_SEND transaction program name (FS2) 
DS_RECEIVE transaction program name (FS2) 
SNA/MS Change Management agent TP name 


SNA/File Services server name 


Object Distribution transaction program for IBM System 36 and 


system 38. 


Object Distribution server transaction program for IBM System 


36 and System 38. 
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Code Points Used by SNA/DS FS2 


The values of the ID component of the LLID structure as used for SNA/DS GDS 
variables are shown below: 


ID Structure Name 

1532 SNA Condition Report 

1570 Transport Prefix 

1571 Transport Command 

1572 Destination List 

1573 Agent Object 

1574 Server Object 

1575 Report Command 

1576 Report Information 

1577 Receiver Exception Command 
1578 Sender Exception Message Unit (type FS2) 
1579 Completion Query Message Unit 
157A Completion Report Message Unit 
157B Continuation Prefix 

157C Report Prefix 

157E Purge Report Message Unit 

157F = Suffix 

1580 Supplemental Distribution Info2 
1582 Reported-On Supplemental Distribution Info2 
1583 Report-To DSU/User 

1585 Reset Request Message Unit 
1586 Reset Accepted Message Unit 
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Code Points Used by SNA/DS FS‘ 


The values of the ID component of the LLIDF structure as used for SNA/DS GDS 
variables are shown below:? 


ID Structure Name 
C001* In DIA, MU PREFIX; in DS, Prefix within DIST _MU or within REMU (type 
FS1) 


C101* in DIA, MU CMD NO REPLY ACKNOWLEDGE; in DS, Command within 
REMU (type FS1) 


C105 Command, DIST_MU 


C322* in DIA, MU OPERAND IMM DATA EXCEPTION-CODE; in DS, Exception 
Code, within REMU (type FS‘) 


C328* in DIA, MU OPERAND IMM DATA DATA CORRELATION; in DS, Corre- 
lation, within REMU (type FS1) 


C32D* in DIA, MU OPERAND IMM DATA USER-DATA; in DS, Agent Object 
within DIST_MU 


C33D* in DIA, MU OPERAND IMM DATA STATUS-INFORMATION; in DS, Dis- 
tribution General Options, within DIST_MU 


C340* in DIA, MU OPERAND IMM DATA DISTRIBUTION-IDENTIFIER; in DS, 
Distribution Identifier, within DIST_MU 


C343* in DIA, MU OPERAND IMM DATA GENERAL-ROUTING-DATA; in DS, 
Report-To Options within DIST_MU 


C345* in DIA, MU OPERAND IMM DATA REPLY DATA; in DS, Reply Data, 
within REMU (type FS1) 


C350 Beginning of Destination Operand Lists, of the Specific Report Lists, 
within DIST_MU 


C351 End of Destination Operands Lists, of the Specific Report Lists, within 
DIST_MU 


C352 Routing Group Name (RGN) of Destination Operands, within DIST_MU 
C353 Routing Element Name (REN) of REN List, within DIST_MU 

C354 Distribution Group Name (DGN) of DGN List, within DIST _MU 

C355 Distribution Element Name (DEN) of DEN List, within DIST _MU 

C356 Report Type, within DIST_MU 

C357 Report Contents, within DIST_MU 

C360 Report-To Address, within DIST_MU 

C361 Receiving DSU, within DIST_MU or within REMU (type FS‘) 


2 The asterisk following the ID indicates that that identifier is used by both DIA (Document Interchange Architec- 
ture) and DS. 
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C908 Server Object, within DIST_MU 
CS9OA_—s Server Prefix, within DIST_MU 


CFO1* = in DIA, MU SUFFIX NORMAL-TERMINATION; in DS, Suffix within 
DIST_MU or within REMU (type FS1) 


CFO2* in DIA, MU SUFFIX ABNORMAL-TERMINATION; in DS, SEMU (type FS1) 
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Terminology Mappings 


Table 85 (Page 1 of 3). Terminology Mappings 
FS2 TERMINOLOGY Current FS1 TERMINOLOGY Old FS1 TERMINOLOGY 


Dist_Transport_MU Dist_MU (type Transport) Dist_IU (type Data) 


Transport_Prefix Prefix Prefix 
Hop_Count Hop Count Dist_Dest_Hops 
MU_ID es a 


Dist_CMD 
Dist_Flags 
DSL 

Data Size 
Dest_TPN 
Server _Name 


Dist_Command 
Dist_ Flags (FS1) 
Service_Parms 


Transport_Command 
Dist_Flags 
Service_Parms 


Server_Obj_Byte_Count Server_Obj Byte_Count 


Origin _Agent Origin_Agent 
Server Server 
Origin DSU 

Origin RGN 

Origin_REN 

Origin _User 

Origin_DGN 

Origin_DEN 

Seqno_DTM 
Supplemental_Dist_Infot 


Orig_RGN 
| Orig REN 


Origin RGN 
Origin _REN 


Orig DGN 
Orig_DEN 
Orig Seqno, Orig DTM 


Origin_DGN 
Origin _DEN 
Origin _Seqno, Origin. DTM 


Agent_Correl Agent_Correl Orig_Correl 
Report-To_DSU 
Report-To_RGN 
Report-To_REN 
Report-To_User 
Report-To_DGN 
Report-To_DEN 


Report_Service_Parms 


Fdbk_RGN 
| Fdbk_REN 
Fdbk_DGN 
Fdbk_DEN 
Fdbk_ DSL 
Fdbk TPN 


Report-To_RGN 
Report-To_REN 


Report-To_DGN 
Report-To_DEN 
Report_Service_Parms 


Report-To_Agent Report-To_Agent 


Dest_Agent 


Unrecognized_Reserve 


Dest_List Destination_Operands Destination _Operands 
Dest — es 

Dest_DSU — po 

Dest_RGN Dest_RGN Dest_RGN 

Dest_REN | Dest_REN Dest_REN 

Dest_User as _ 

Dest_DGN Dest_DGN Dest_DGN 

Dest_DEN Dest_DEN Dest_DEN 


Agent_Object 
Server_Object 


Dest_Appl_Parms 
Distrib_Object_Data 


Agent_Object 
Server_Object 


Supplemental_Dist_Info2 
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Table 85 (Page 2 of 3). Terminology Mappings 


FS2 TERMINOLOGY Current FS1 TERMINOLOGY Old FS1 TERMINOLOGY 


DS_Suffix 
| Dist_MU (type Report) 


DS_ Suffix 
Dist_Report_MU 
Report_Prefix 
Report_Command 
Reporting DSU 
Reporting_RGN 
Reporting REN 
Report_DTM 
Report-To_DSU_User 
Report_Information 
Reported-On_Origin_DSU 
Reported-On_Origin_RGN 
| Reported-On_Origin_REN 
Reported-On_Origin_User 
Reported-On_Origin_DGN 
Reported-On_Origin_DEN 
Reported-On_Seqno_DTM 


Reported-On_Supp_Dist_Info1 
Reported-On_Supp_Dist_Info2 
Reported-On_Agent_Correl 
Reported-On_Dest_Agent 
|SNA_Condition_Report 
SNA_Report_Code 
Structure_Report 
Structure_State 
Structure_Contents 
Parent_Spec 
Parent_ID_Or_T 
Parent_Class 
Parent_Position 
Parent_Instance 
Structure_Spec 
Structure_ID_Or_T 
Structure_Class 
Structure_Position 
Structure_Instance 
Structure_Segment_Num 
Structure_Byte_Offset 
Sibling _List 
Reported-On_Dest_List 
Reported-On_Dest_Pfx 
Reported-On_Dest 


Reported-On_Origin_DGN 
Reported-On_Origin_DEN 


Reported-On_Seqno, 
Reported-On_DTM 


Reported-On_Agent_Correl 


Specific_Report 
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Suffix 
Dist_IU (type Status) 


Orig DGN 
Orig_DEN 
Orig _Seqno, Orig DTM 


Orig _Correl 


Specific_Status 


Table 85 (Page 3 of 3). Terminology Mappings | 
FS2 TERMINOLOGY Current FS1 TERMINOLOGY Old FS1 TERMINOLOGY 


Reported-On_Dest_DSU 
Reported-On_Dest_RGN 
Reported-On_Dest_REN 
Reported-On_Dest_User 
Reported-On_Dest_DGN 
Reported-On_Dest_DEN 
Reported-On_Dest_Sfx 
Supplemental_ Report 
Dist_Continuation_MU 
Continuation_Prefix 

Restarting Byte_Position 
Sender_Exception_MU 
Receiver_Exception_MU 
Receiver_Exception Command 
Sender_Retry_Action 
Receiving DSU 

Receiving RGN 

Receiving REN 
Completion_Query_MU 
Completion_Report_MU 
Indicator_Flags 
Last_Structure_Received 
Last_Byte_Received 
Purge_Report_MU 
Reset_Request_MU 
Reset_DTM 
Reset_Accepted_MU 


Reported-On_Dest_DGN 
Reported-On_Dest_DEN 


Sender_Exception_MU 


Receiver_Exception_MU 
Receiver_Exception_Command 
Receiving DSU 

Receiving RGN 

Receiving_REN 


Suffix (type 2) 
Ack_IU 
Ack_Cmd 
Rcev_DSUN 
Rcv_DSUN_RGN 
Rcv_DSUN_REN 


Appendix G. Encodings 637 


638 SNA/Distribution Services Reference 


Glossary 


Glossary terms are defined as they are used in this 
book. If you cannot find a term in this glossary, refer 
to the index or to the glossary in SNA Technica/ Over- 
view, GC30-3073. 


A 


Agent. An application program that submits and 
receives information to and from the distribution 
service, across the agent protocol boundary. 


Agent Object. Small amounts of data submitted for 
distribution by the origin agent. The agent object is 
stored and distributed by DS and passed directly to 
the destination agent. Larger amounts of data, or 
data that requires a particular kind of handling 
(encryption, for example, or specialized parsing) 
usually flow in the server object. 


Agent Protocol Boundary. The logical interface 
between agents or operators and SNA/DS. 


Alternate Routing. An implementation-defined mech- 
anism that provides an alternate route in the routing 
table when connections are unavailable for a partic- 
ular combination of destination DSU and service 
parameters. 


Auxiliary Server Operation. The copy-making steps 
performed when transferring the server object 
between the specific server and the general server. 


Bilingual DSU. A DSU that acts as a gateway 
between FS1-only portions of the DS network and 
FS2-supporting portions, translating between the 
format sets as necessary. 


Byte-Count Restart. A type of Mid-MU restart 
whereby the transmission of the server object can be 
restarted at any byte position. 


Cc 


Capacity Service Parameter. The service parameter 
that describes the required storage capacity for the 
distribution. 


Completion Query Message Unit (CQMU). A control 
message unit sent by the sending DSU to query the 


completion status of a particular message unit at the 
receiving DSU. 


Completion Report Message Unit (CRMU). A control 
message unit sent by the receiving DSU to report on 
the completion status of a particular message unit. 


Connection. In SNA/DS, the set of concurrent conver- 
sations with a particular partner LU using a particular 
mode name. A connection may consist of one or 
more than one conversation. 


Connection-Oriented Service. A communications 
service that provides a direct connection between the 
communicating parties. 


Connectionless Service. A service that performs 
communication without the establishment of a direct 
connection between (or among) the communicating 
parties. 


Control Message Unit (CMU). A type of message unit 
containing information about a conversation or about 
a DMU. The control information is used strictly by 
adjacent DSUs to manage traffic between the DSUs. 
CQMUs, CRMUs, PRMUs, RAMUs, REMUs, RRMUs, 
and SEMUs are referred to collectively as control 
message units. 


D 


Default Directing. The use of default “tokens” (the * 
in this documentation) in place of parts of the user 
name. Default directing alleviates the need to specify 
every user name or every agent name in every local 
directory throughout the network. 


Default Routing. The use of default “tokens” (the * in 
this documentation) in place of parts of the DSU 
name. Default routing alleviates the need to specify 
every DSU name in every routing table throughout 
the network. 


Destination. One of the intended recipients of a dis- 
tribution. A destination may be either a user or DSU 
(node). 


Destination DSU. A DSU at which one or more recipi- 
ents of a distribution reside. 


Destination Server. A server used at the destination 


DSU to store the server object in an application’s 
private storage space. 
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Direct Fetch. An implementation elective that 
bypasses the auxiliary server operation from the spe- 
cific server to the general server. The outgoing 
server object is directly retrieved using the specific 
server at send time. 


Direct Store. An implementation elective that 
bypasses the auxiliary server operation from the 
general server to the specific server. The incoming 
server object is directly stored into an application’s 
(or user’s) private space at receive time. 


Directing Sublayer. The DS sublayer responsible for 
associating a DSU name with every destination user 
name in a distribution and for determining, at the 
destination(s) of a distribution, local delivery informa- 
tion for each destination. 


Distribution. (1) In general, the function of trans- 
porting information from an origin to one or more 
destinations in a DS network; a distribution is the 
result of a specific request for distribution service. (2) 
A synonym for the actual data transported by DSUs in 
honoring such a request; see distribution message 
unit (DMU). 


From the perspective of the user or agent, a distrib- 
ution is the complete set of results of a request. It 
may sometimes be appropriate from that perspective 
to refer to the parts of the distribution flowing along 
different routes as distribution copies. 


From the perspective of a particular Distribution 
Service Unit (DSU), a distribution may be complete or 
it may be only a copy of a larger distribution. From 
that DSU’s perspective every distribution copy being 
processed through it is referred to as a distribution. 

A receiving DSU cannot determine whether or not it 
has received the only copy of a particular distribution. 
Therefore, every distribution copy being processed by 
that DSU is referred to as a distribution. 


Distribution Continuation Message Unit (DCMU). A 
distribution message unit used by a sending DSU to 
continue transmission of a suspended message unit. 


Distribution Copy. The result of transmitting a dis- 
tribution. Each distribution copy contains some or all 
of the complete set of destinations for the entire dis- 
tribution. 


Distribution Element Name (DEN). The second part of 
a distribution-user name. The user element name 
(DEN) is unique within its particular group (DGN). 


Distribution Group Name (DGN). The first part of a 
distribution-user name. The distribution group name 
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(DGN) is unique throughout the DS network. The DGN 
is intended to be a convenient and natural grouping of 
names, with no reference to a location. 


Distribution Identification. The collection of struc- 
tures in the DTMU that uniquely identifies a distrib- 
ution in the DS network. The dist_/D consists of the 
origin DSU name, origin user name (if any), origin 
agent name, a sequence number, and a date. 


Distribution Message Unit (DMU). A type of 
message unit used to convey distribution information 
between DSUs. DTMUs, DRMUs, and DCMUs are 
referred to collectively as distribution message units. 


Distribution Report. Information, provided in a 
DRMU by the detecting DSU in the DS network, on 
the condition of a distribution. 


Distribution Report Message Unit (DRMU). A distrib- 
ution message unit containing a distribution report. 


Distribution Services (DS). See SNA/Distribution 
Services. 


Distribution Service Unit (DSU). The collection of 
distribution transaction programs and data structures 
(e.g., queues, routing tables, user directory) that 
provide the distribution service at a particular 
location in a DS network. 


Distribution Transport Message Unit (DTMU). A dis- 
tribution message unit used to deliver the information 
given in a distribution request to the specified desti- 
nations. 


Distribution Transport Sublayer. The DS sublayer 
responsible for sending and receiving MUs between 
adjacent DSUs. This sublayer manages the LU 6.2 
conversations and provides encoding and decoding of 
MUs. 


DSU Name. The name of a distribution service unit. 
The DSU name consists of two parts, the routing 
group name and the routing element name. It identi- 
fies a specific location in the DS network. Users typi- 
cally are not aware of DSU names (i.e., RGNs and 
RENs). 


DSU Role. The function performed by a DSU while 
processing a particular distribution. A DSU may play 
any of several roles, depending upon the distribution 
(e.g., the DSU at which a distribution is originated 
plays the role of the origin; a DSU that receives a dis- 
tribution and forwards it to another DSU plays the 
role of an intermediate DSU). 


Early Acceptance. The process by which a specific 
server reports a partially successful server operation 
to the local agent, and allows DS to process the 
remainder of the distribution normally. 


Elective. An implementation choice as to how or 
when a function is provided, made for performance or 
development cost reasons. All permissible electives 
are defined by the architecture, since the effects of an 
elective are observable outside the DSU. 


Exception Hold. The process of holding the next-DSU 
queue to stop transmission to the adjacent DSU, 
because an exception condition was encountered. 
The hold can be released by the operator or by the 
initiation of a new instance of DS_ Send. 


F 


Fan-Out. The process of creating copies of a distrib- 
ution to be delivered locally or to be sent through the 
network. 


Format Set 1 (FS1). The earlier version of the DS 
formats and protocols. 


Format Set 2 (FS2). The current version of the DS 
formats and protocols. 


G 


General Server. A server that DS uses to store and 
retrieve server objects in DS storage space. 


Intermediate DSU. A DSU through which a distrib- 
ution passes on its way from the origin DSU to the 

destination DSU(s). An intermediate DSU receives, 
routes, and may redirect the distribution before for- 
warding it. 


L 


LLID. The introducer of a length-bounded encoding 
structure whose identifier is two bytes long. 


LLID Restart. A type of Mid-MU restart whereby the 
transmission is resumed at the beginning of an LLID 
structure in the DMU. 


Local Reports. Information provided to the agent on 
a condition that occurred before DS accepted respon- 
sibility for the distribution request or when DS was 


performing some application-specific operation (e.g., a 
specific server operation). Local reports are deliv- 
ered to the agent across the agent protocol boundary. 


Location-independent. The property of a user name 
whereby it does not depend on the DSU at which the 
user resides. This provides the ability to move users 
from one DSU to another without changing their user 
names. 


LT. The introducer of a length-bounded encoding 
structure whose identifier is one byte long. 


LU 6.2 Conversation. !In SNA, a logical connection 
between two transaction programs using an LU 6.2 
session. Conversations are delimited by brackets to 
gain exclusive use of a session. 


LU 6.2 Protocol Boundary. The logical interface 
between LU 6.2 and DS across which information is 
passed. 


Message Unit (MU). In general, an architecturally 
defined structure for information communicated from 
one process to another. In DS, the entity that flows 
between distribution service units. 


Mid-MU Restart. The capability of restarting a failed 
transmission at or near the point of failure, rather 
than retransmitting from the beginning. 


N 


Node Destination. See Destination. 


O 


Operator. A person or program that interacts with 
the DSU by issuing commands to perform such tasks 
as system or network maintenance functions. 


Operator Hold. The process of holding a distribution 
or the next-DSU queue in response to operator action. 


Option Set. An architecturally defined group of DS 
functions. All DS implementations support the base 
set of DS functions, and may choose which option 
sets to support, if any. 


Origin DSU. The DSU at which the originator of a dis- 
tribution resides. 


Origin server. The server, named in the distribution 


request, from which DS is to obtain the server object 
to distribute. 
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Other-Assignment. The name given to the action of 
assigning read access to the server object, whenever 
the issuer of the Assign_Read_Access verb specifies 
a different value for the assigning_process and 
assigned_process. 


p 


Presentation Services Sublayer. The DS sublayer 
with which agents and operators interact. 


Priority Service Parameter. The service parameter 
used to specify the relative uigency of a particular 
distribution. 


Protection Service Parameter. The service parameter 
used to specify whether the distribution must be 
stored on non-volatile storage while a DSU has 
responsibility for it. 


Protocol Boundary. A logical interface that defines 
the interactions between DS and another entity. The 
boundary defines the functions provided by and 
expected by the entities on either side of the 
boundary. 


Protocol Boundary Verb. A logical command or 
request issued across a protocol boundary. 


Purge Report Message Unit (PRMU). A control 
message unit transmitted by the sending DSU to 
inform the receiving DSU that the sender has marked 
a particular MU_ID as PURGED in its MU_ID registry. 


Q 


Queue Protocol Boundary. The logical interface 
between the queue manager and DS across which 
information is passed. 


R 


Receive Time. The period of time required by a DSU 
to receive a DMU. 


Receiving Sequence. A sequence of verbs issued by 
an agent to receive a distribution. 


Receiver Exception Message Unit (REMU). A control 
message unit transmitted by the receiving DSU to 
the sending DSU when the receiver detects an excep- 
tion while receiving a DMU. 


Redirection. The process whereby DS receives a dis- 


tribution, changes one or more DSU names (for one 
or more destinations), and forwards the distribution. 
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Report Service Parameters. The parameters supplied 
by the origin agent to specify the level of service 
requested for the distribution report. The origin agent 
supplies report service parameters when it wants to 
override the service parameters that would be rou- 
tinely generated for the report by the reporting DSU. 


Report-to Agent. The agent, specified by the origi- 
nator, that will be invoked to receive the distribution 
report. If an agent is not explicitly defined, the origin 
agent will be invoked to receive the distribution 
report. 


Reset Accepted Message Unit (RAMU). A control 
message unit sent by the receiving DSU, in response 
to an RRMU, to inform the sending DSU that the 
MU_ID registry at the receiving DSU has been reset. 


Reset Request Message Unit (RRMU). A control 
message unit sent by the sending DSU to request the 
receiving DSU to reset its MU_ID registry. 


Responsible DSU. For a distribution on which 
reporting has been requested, the DSU that must gen- 
erate the distribution report in the event of an excep- 
tion. 


Reversible Server. A server that can store an object 
and later retrieve a byte-perfect copy of the object. 


Routing Element Name (REN). The second part of the 
two-part DSU name. The routing element name (REN) 
must be unique within its particular group (RGN). 


Routing Group Name (RGN). The first part of the 
two-part DSU name. This is typically, but not neces- 
sarily, the network ID. 


Routing Sublayer. The DS sublayer that determines 
where to send distributions based on the DSU names 
in the destination list. For local destinations, the dis- 
tribution is passed to the directing sublayer; for 
remote destinations, the distribution is placed on the 
appropriate next-DSU queue(s). 


Routing Table. A table which defines the connection 
to be used to forward a distribution to a particular 
destination at a particular level of service. 


S 


Security Service Parameter. The service parameter 
used to specify whether the distribution is to be 
routed through the SNA/DS network using only ses- 
sions defined as secure. 


Self-Assignment. The name given to the action of 
assigning read access to the server object, whenever 
the issuer of the Assign _Read_Access verb specifies 


the same value for the assigning_process and 
assigned_process. 


Send Time. The period of time required by a DSU to 
send a DMU. 


Sender Exception Message Unit (SEMU). A control 
message unit transmitted by the sending DSU to 
inform the receiving DSU that the sending DSU has 
encountered an exception while sending a DMU. 


Sending Sequence. A sequence of verbs issued by 
an agent to originate a distribution. 


Server. The process that fetches and stores server 
objects and controls access to them. 


Server Access. Information provided to a server that 
is used to access the server object. 


Server Object. Data specified by the originator of the 
distribution that is to be retrieved and stored using a 
server. 


Server Protocol Boundary. The logical interface 
between servers and the distribution service across 
which distribution objects are passed. 


Service Parameters. The parameters used to map 
particular types of DS traffic to particular classes of 
service offered by the lower layers of SNA. 


SNA Condition Report (SNACR). A standard struc- 
ture used by SNA components to report exception 
information. The structure contains the report code 
describing the condition and may provide additional 
supporting information. 


SNA/Distribution Services (SNA/DS). A 
connectionless communications service that distrib- 
utes objects over a network of LU 6.2 connections. 


Specific Server. A server that stores objects into and 
fetches objects from an application’s private storage 
space. A specific server may be sensitive to the con- 
tents of the byte streams it processes. 


Specific Server Information. Instructions provided for 
the specific server to build and process the object 
prior to presenting it to DS. 


Tt 


Transaction Programs. In DS, the processes that 
provide the distribution service, as well as the agents 
and servers with which the distribution service inter- 
acts. 


U 


User Destination. See Destination. 


User Directory. From the perspective of a particular 
distribution service unit (DSU), a local table of entries 
that relates a remote user name to the name of the 
distribution service unit at which the user can receive 
distributions. 


From the perspective of the network, the directory is 
the collection of the individual user directories from 
all the DSUs in the network. Every distribution user 
must have at least one entry in the collective user 
directory. 


The directory may include additional user information 
not related to the distribution service. The directory 
may also include entries for users not associated with 
the distribution service. 


User Name. A two-part name for distribution users. 
It is intended to be a convenient and reasonably 
friendly name for users, e.g., ACCT.JONES Or MKT.SMITH. 
It is not intended to include any reference to the 
user’s location in the network. 
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Cc 
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1134 (AR) 629 
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child 555 
closed protocol boundary 366 
specializations 380 
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CRMU_ 95, 566 
CRMU-PRMU exchange 75 


D 
data structures 
list of 69 
of transport sublayer 72, 146, 224 
DCMU 98, 563 
default directing 36 
default routing 38 
delete a queue entry 357 
dequeue 
from control MU queue 189, 235 
from local-delivery queue 120 
from Mid-MU Restart queue 263, 277 
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from Router-Director queue 127 
designing an implementation 365 
destination 
list 582 
role 368 
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destination-only role 368 


DS_Receive (continued) 


DIA 384 FS2 
DiA report 387 exception handling 421 
differences in reporting 382 FSMs 224 


direct fetch 47, 420 
direct store 47, 425 


DS_Router_Director 
exception handling 427 


directing 13, 373 FSMs_ 121 
exceptions 427 DS_Send 71 
FSMs 128 FS1 
Directory 10 exception handling 431 
distribution 6 FSMs 285 
copy 7 FS2 
flags 569 exception handling 417 
identification 8 FSMs 146 
log 377 DTMU 7, 560 


report 66, 372, 405 


Distribution Continuation Message Unit (DCMU) 98, 
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duplicate destinations 371 
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Distribution Report Message Unit (DRMU) 8, 66, 562 end-only role 368 

Distribution Report Operands 608 enhanced character strings (930) 375 
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bilingual 383 enqueue 
definition 69 to local-delivery queue 135 
directing sublayer 128 to mid-MU Restart queue 243 
finite state machines 107, 363 to next-DSU queue 143 
name 9 to Router-Director queue 119, 263, 327 
presentation services 119 exception 
role 9 detected by transport sublayer 89, 94 
routing sublayer 136 exception action (FS1) 430 
structure of 107 exception analysis (FS2) 64, 416 
transport sublayer exception condition characteristics 407 
FS1 285 exception conditions (FS1) 429 
FS2 146 exception handling (FS1) 429 
unattended 366 7 exception hold 407 
distribution transport 71 exception log 406 
FS1 exception processing 63, 65 
DS Receive 310 distribution transport 89 
DS Send 285 exception protocols 89 
FS2 | exception report 
DS Receive 224 flag 569 
DS Send 146 
Distribution Transport Message Unit (DTMU) 7, 560 F 
distribution transport sublayer 71, 146, 285 
DMU_ 8, 606 fan-out 16 
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exception handling 434 DS_RCV_DISCARD_DIST 276 
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finite state machines (continued) 


DS_RCV_MANAGER 232 
DS_RCV_MU_ID HANDLER 244 
DS_RCV_MU_ID REGISTRY 280 
DS_RCV_MU_STATE_DESCRIPTION 104 
DS_RCV_PRMU_HANDLER 272 
DS_RCV_RECEIVE DMU 240 
DS_RCV_RECEIVE DMU_NO_MU_ID 259 
DS_RCV_RECEIVING 237 

DS _RCV_REMU_SUSP_TERM 254 
DS_RCV_SEMU_HANDLER 269 

DS _RCV_SENDING 234 
DS_RCV_SEND_ CONVERSATION MGR 278 
DS _RCV_SEND ERR 246 
DS_RCV_SEND ERR_CRMU 256 

DS _RCV_SEND ERR_REMU 248 


DS_RCV_SEND ERR SUSP_TERM_REMU 252 


DS _RCV_SUSP DIST 274 
DS_RCV_SUSP_TERM 250 

DS SEND BUILD SEND _DMU 163 

DS SEND CHECK CONV FAIL 212 

DS SEND CLEANUP_DMU 166 
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